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I.  INTRODUCTION 


Developing  a  high  assurance  system  requires  the  building  of  a  security  model  that 
is  verified  using  formal  methods.  Theorem  provers  and  model  checkers  are  some  of  the 
formal  method’s  tools  that  help  to  build  specifications  for  a  security  model  and 
mathematically  verify  their  correctness. 

Former  NPS  students  have  explored  various  fonnal  specification  tools  such  as 
PVS  [1],  Specware  [2]  and  Alloy  [3]  for  their  usefulness  in  formally  specifying  a  security 
model  to  represent  security  policies  and  verify  their  correctness. 

In  this  thesis  we  are  revisiting  Specware,  an  “automated  software  development 
system”  [4]  by  Kestrel  institute.  It  exploits  category  theory  to  capture  the  refinement  of 
specifications  into  code  and  the  composition  of  software  components.  In  DeCloss’s  thesis 
[2],  it  is  mentioned  that  the  Snark  automated  theorem  prover  bundled  with  Specware  “is 
deficient  in  multiple  ways  including  insufficient  logging  capabilities”  [2]. 

Specware  has  since  included  a  translator  to  translate  a  Specware  specification  to 
an  Isabelle  Specification.  Isabelle  is  a  generic  proof  assistant  that  “allows  mathematical 
formulas  to  be  expressed  in  a  formal  language  and  provides  tools  for  proving  those 
formulas  in  a  logical  calculus”  [5].  We  are  demonstrating  in  this  thesis  that  a 
specification  in  Specware  can  be  translated  to  Isabelle  using  the  tool.  We  will  explore, 
though  not  in-depth,  some  proving  capabilities  of  Isabelle.  A  number  of  simple  proofs 
will  be  demonstrated  in  this  thesis. 

State  changes  are  common  in  most  security  models.  We  are  exploring  the  use  of  a 
recursive  function  and  Monad  to  represent  state  changes.  Monad  was  mentioned  in 
DeCloss’s  Thesis  [2]  as  future  work  and  we  will  explore  and  demonstrate  how  state 
changes  can  be  represented  using  State  Monad. 

This  thesis  presents  our  encounter  and  experience  with  security  modeling  using 

the  latest  version  of  Specware  and  auto-proving  with  Isabelle  and  our  follow-up  work  on 

Decloss’s  Thesis.  We  begin  by  first  presenting  a  brief  overview  of  Specware,  its 

specification  language  MetaSlang  and  Isabelle.  We  then  describe  our  approach  in 
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learning  the  concepts  of  security  modeling  and  modeling  and  discuss  the  intermediate  and 
final  models  we  built.  We  then  conclude  with  our  analysis  of  Specware  and  Isabelle,  and 
present  our  learning  experience,  together  with  recommendations  for  future  work. 


2 


II.  BACKGROUND 


A.  FORMAL  METHODS,  MODELS  AND  VERIFICATION 

Formal  methods  are,  as  described  by  Wing  [6],  mathematically  based  techniques 
to  describe  system  properties.  A  method  is  fonnal  if  it  has  a  sound  mathematical  basis, 
and  this  provides  the  means  to  precisely  define  notions  like  consistency  and 
completeness;  and  more  relevantly,  specification,  implementation  and  correctness, 
typically  using  a  fonnal  specification  language.  Formal  method  provides  the  means  to 
prove  properties  of  a  system  without  necessarily  running  it  to  detennine  its  behaviour, 
that  a  specification  is  realizable  and  that  a  system  has  been  implemented  conectly. 

A  formal  model  is  one  constructed  from  requirements  and  infonnal  rules  and 
policies  on  the  system.  It  is  a  precise  and  unambiguous  statement  of  a  system’s  security 
policy.  For  example,  for  a  security  model,  mapping  is  performed  to  map  a  security  policy 
to  a  mathematical  model.  It  is  then  informally  argued  that  the  model  is  consistent  with 
the  security  policy.  If  the  model  is  an  accurate  restatement  of  the  policy  and  if  the  model 
is  self  consistent,  we  can  conclude  that  the  policy  is  self  consistent. 

A  formal  specification  refers  to  the  specification  for  a  created  formal 
mathematical  model  (Formal  Model).  It  is  a  precise  definition  of  what  the  software  is 
intended  to  do  [7].  It  differs  from  conventional  design  specifications  in  that  it  is 
concerned  only  with  the  function  of  the  system  and  makes  no  commitments  to  its 
structure.  In  particular,  a  formal  security  policy  model  is  concerned  with  the  security  of 
the  system.  A  specification  is  abstract  and  specifies  what  is  to  be  done  instead  of  how  it 
is  done.  It  specifies  only  whatever  level  of  detail  is  necessary,  leaving  unsaid  what  is 
deemed  unimportant.  A  specification  is  central  to  a  project,  and  proofs  of  the 
specification’s  properties  are  at  least  as  useful  as  proofs  of  correct  implementation.  The 
formal  specifications  are  proven  to  satisfy  the  mathematical  model. 

Formal  methods  can  be  employed  in  any  stage  of  system  development,  from 
requirement  specification  to  design,  implementation,  testing,  and  maintenance  right  up  to 
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verification  and  evaluation,  although  cost  and  return  of  value  may  differ  for  each  stage.  It 
is  useful  in  unravelling  ambiguity,  incompleteness  and  inconsistency  in  the  system, 
increasing  the  correctness  of  the  system.  Applying  formal  methods  can  benefit  many 
areas  in  addition  to  security,  including  fitness  for  purpose,  maintainability,  ease  of 
construction,  and  better  visibility  [8]. 

Most  formal  methods  have  not  been  applied  to  specifying  large  scale  software  or 
hardware  systems.  Hence,  most  are  still  inadequate  to  specify  many  important 
behavioural  constraints  beyond  functionality  (e.g.,  fault  tolerance,  real-time  performance 
and  human  factors).  There  is  also  a  general  lack  of  integration  between  fonnal  methods 
with  the  entire  system  development  effort. 

The  application  of  formal  methods  is  still  very  much  restricted  to  the  academic 
and  military  fields.  Although  it  is  not  all  about  complicated  mathematics,  it  requires  a 
paradigm  shift  from  normal  software  engineering.  Depending  on  the  support  tools 
chosen,  the  learning  curve  is  not  trivial  and  experience  is  critical  to  develop  a  good 
formal  specification.  Proper  training  is  required  for  formal  methods  practitioners.  The 
success  of  a  formal  method  application  is  very  much  dependent  on  the  quality  of  the 
practitioners  [8]. 

Formal  methods  could  be  broadly  categorised  into  three  groups:  refutation, 
verification  and  intensive  mathematical  study  of  key  programs,  each  with  its  own 
strengths,  weaknesses  and  costs  [8], 

In  refutation,  as  is  employed  in  the  Alloy  Aanlyser,  one  tries  to  refute  the  claim 
that  the  specification  meets  its  requirements  by  searching  for  counterexamples.  It  is 
based  on  the  small  scope  hypothesis  which  states  that  if  an  inconsistency  in  a  model 
exists  there  is  a  high  probability  that  it  will  present  itself  within  a  small  scope  of  the 
model.  The  finding  of  counterexamples  is  not  “absolute  proving”  in  the  strictest  sense, 
although  the  finding  of  one  counterexample  is  enough  to  conclude  that  a  particular 
system  is  insecure.  Often,  model  checking  may  be  slow  as  it  runs  extensively  in  the 
searching  of  counterexamples. 
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Verification  attempts  to  provide  a  basis  by  which  software  can  be  proved  to  be  a 
correct  realization  of  its  specification.  Typically,  this  is  only  carried  out  at  the 
requirements  and  code  level  as  performance  of  formal  methods  drive  up  the  cost 
significantly.  To  reduce  cost,  the  intensive  mathematical  study  of  the  key  programs 
approach  focuses  only  on  the  difficult  and  problematic  part.  This,  however,  carries  the 
danger  that  something  of  security  relevance  might  be  overlooked  unless  the  security 
functions  have  been  factored  into  a  small  number  of  underlying  components.  Automated 
verification  systems  or  theorem  provers  would  be  useful  in  formal  verfication,  as  they  can 
greatly  increase  the  efficiency  and  productivity.  The  general  complaint,  though,  is  that 
they  are  time  consuming  to  use,  costly,  and  to  date  they  are  limited  in  their  ability  to  be 
fully  automated.  Most  require  an  untrival  level  of  guidance  from  the  human  operator  to 
complete  the  proofs.  Successful  verification,  though,  will  give  users  the  assurance  that 
the  software  will  work  and  behave  as  specified,  which  is  crucial  in  security  and  safety 
critical  software. 

The  Common  Criteria  imposes  the  requirement  that  any  system  requiring  a  high 
level  of  trust  (e.g.,  Evaluation  Assurance  Level  7  or  EAL  7)  must  undergo  a  rigours  life 
cycle  including  the  use  of  formal  verification  of  its  security  properties  [9].  Fonnal 
verification  is  incorporated  in  the  development  life  cycle  to  ensure  that  the  system  is 
correct.  While  necessary  for  high  assurance  systems,  the  level  of  effort  associated  with 
manual  verification  can  be  unreasonably  huge  due  to  large  and  complicated  proofs. 

In  the  context  of  the  project,  a  specification  language  and  verification  system 
developed  by  the  Kestrel  Development  Corporation  is  used.  We  attempt  to  build  upon 
the  work  perivously  performed  by  DeCloss,  and  to  evaluate  the  usability  of  the  newer 
features  of  Specware,  the  discharging  of  proof  obligations  directly  to  Isabelle  for  proving 
via  the  Specware  Isabelle  interface,  and  the  modeling  of  the  Least  Privileged  Seperation 
Kernel  using  Monads  and  inbuilt  Set  base  library  in  Specware. 
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B.  INFORMATION  FLOW  ANALYSIS 

1.  Bell  and  LaPadula  (BLP) 

The  concept  of  mandatory  access  controls  was  formalized  by  Bell  and  LaPadula 
in  a  model  commonly  bearing  their  name  [10].  Numerous  variations  of  the  model  have 
since  been  published,  but  only  a  very  simplified  version  will  be  considered  in  the  context 
of  this  paper  for  the  building  of  a  sample  security  model  using  Specware. 

Mandatory  access  control  policy  is  based  on  security  labels  attached  to  subjects 
and  objects.  A  label  on  a  user  and  an  object  are  called  security  clearance  and  a  security 
classification  respectively.  A  user  labeled  secret  can  run  the  same  program  as  a  subject 
labeled  secret  or  as  a  subject  labeled  unclassified,  assuming  the  program  is  labeled 
unclassed.  Even  though  both  the  subjects  run  the  same  program  on  behalf  of  the  same 
user,  they  obtain  different  privileges  due  to  their  security  labels.  For  the  purpose  of  the 
example  in  this  thesis,  only  the  notion  of  subject  and  object  will  be  considered. 

Mandatory  access  BLP  rules  can  be  expressed  as  follows,  with  SecLabel 
representing  the  security  label  of  the  indicated  subject  or  object: 

•  Simple  security  property:  Subject  s  can  read  object  o  only  if  SecLabel(s) 
dominates  SecLabel(o). 

•  *-property:  Subject  s  can  write  object  o  only  if  SecLabel(o)  dominates 
SecLabel(s). 

2.  Least  Privilege  Separation  Kernels  (LPSK) 

The  separation  kernels  concept  was  introduced  in  1981  by  Rushby  [11].  A 
separation  kernel  divides  all  the  resources  into  blocks,  sometimes  called  “partitions.”  The 
actions  of  an  active  resource  in  one  block  are  isolated  from  another  active  resource  in 
another  block,  unless  a  communication  is  explicitly  defined  [12].  The  common 
application  of  the  separation  kernels  concept  includes  Virtual  Machine  Monitors  (VMM), 
process  isolation,  enforcing  avionic-related  policies,  and  security  policies  [12].  A 
separation  kernel  where  resources  are  allocated  to  blocks  in  a  fixed  manner  is  called  a 
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static  separation  kernel  and  is  desirable  for  simplicity  of  design  [3].  The  Principle  of 
Least  Privilege  [13]  is  fulfilled  by  granting  only  the  least  set  of  privilege  to  an  active 
resource  in  LPSK. 

Part  of  this  thesis  attempts  to  implement  a  security  model  based  on  “A  Least 
Privilege  Model  for  Statics  Separation  Kernels”  [12]  published  by  The  Center  for 
Information  Systems  Security  Studies  and  Research  (CISR)  at  the  Naval  Postgraduate 
School  (NPS). 

C.  SECURITY  MODELING  AND  ANALYSIS 

The  thesis  demonstrates  different  ways  in  modeling  BLP  and  LPSK  using 
Specware  and  attempts  to  verify  the  correctness  using  Isabelle.  State  transitions  modeled 
using  recursive  function  and  state  monads  are  explored.  Two  types  of  proofing 
approaches,  apply-style  proof  and  structured  Isar  proof,  in  Isabelle  are  also  explored. 
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III.  OVERVIEW  OF  SPECWARE  AND  ISABELLE 


A.  SPECWARE  DESCRIPTION 

Specware  is  a  tool  used  for  building  and  manipulating  a  collection  of  related 
specifications.  It  is  a  design  tool,  a  logic  tool,  a  programming  language,  and  at  the  same 
time  a  database  storing  and  manipulating  collections  of  concepts,  facts  and  relationships. 
It  can  be  used  to  develop  domain  theories,  develop  code  from  specifications,  and  also  for 
reverse  engineering  to  derive  a  specification  from  existing  code  [14].  It  uses  notions  and 
procedures  based  on  category  theory  and  related  mathematics  to  manipulate 
specifications  [15]. 

Composition  and  refinement  are  the  core  techniques  of  application  building  in 
Specware.  Complex  specifications  can  be  composed  from  simpler  ones  and  concrete 
specifications  may  be  refined  from  abstract  ones.  Through  refinement,  a  more  specific 
case  of  a  model  is  built  [17]. 

Specware  is  designed  with  the  idea  that  large  and  complex  problems  can  be 
specified  by  combining  small  and  simple  specifications.  The  problem  specifications  may 
be  further  refined  into  a  working  system  by  the  controlled  stepwise  introduction  of 
implementation  design  decisions,  in  such  a  way  that  the  refined  specifications  and 
ultimately  the  working  code  is  a  provably  correct  refinement  of  the  original  problem 
specification  [14]. 

There  are  three  major  objectives  in  the  design  of  Specware.  First,  it  seeks  to 
provide  a  way  to  express  requirements  as  fonnal  specifications,  independent  of  the 
ultimate  implementation  or  target  language.  Users  can  then  focus  on  correctness,  which 
is  crucial  to  the  reliability  of  the  system.  Second,  it  keeps  the  problem  analysis  process 
separated  from  the  implementation  process.  Implementation  choices  can  be  introduced 
piecewise,  making  backtracking  and  alternative  exploration  possible.  Third,  it  allows  the 
articulation  of  software  requirements,  making  of  implementation  choices  and  generation 
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of  provably  correct  code  in  a  formally  verifiable  manner,  facilitating  system  maintenance 
and  adaption  of  specifications  to  new  or  changed  requirements. 

Specware  interfaces  with  and  performs  logical  inference  and  proving  using 
external  theorem  provers  like  SRI’s  SNARK  theorem  prover  and  Isabelle.  External 
provers  are  connected  to  Specware  through  logic  morphisms,  which  relate  logic  to  each 
other.  SNARK  is  an  automatic  theorem  prover  that  is  difficult  for  allowing  users  to  verify 
the  proof  as  it  provides  insufficient  logging  capabilities  [2],  Isabelle  is  an  interactive 
theorem  prover  that  provides  more  feedbacks  to  the  user. 

The  version  of  Specware  used  for  the  project  is  4.2.2.  An  unofficial  release  of 
Specware  version  4.2.5  was  also  used  in  the  later  stage  of  the  project  which  supports  Set 
and  has  additional  support  for  Monads. 

B.  SPECWARE  FUNCTIONALITY 

1.  MetaSlang 

MetaSlang,  based  on  higher-order  logic,  is  the  specification  and  programming 
language  used  in  Specware.  The  Specware  Language  Manual  contains  a  description  and 
(extended)  BNF  of  the  grammar  of  the  Metaslang  language.  An  extracted  portion  of  the 
core  grammar  is  shown  here  but  it  is  not  intended  to  be  comprehensive.  The  reader  is 
recommended  to  refer  to  the  Specware  documentation  for  a  more  complete  explanation. 

MetaSlang  is  essentially  a  functional  language.  It  includes  syntactic  constituents 
for  describing  functional  semantics  within  a  specification  as  well  as  constructs  for 
describing  composition,  refinement,  code  generation,  and  proof  capabilities.  Specification 
constituents  include  types,  expressions,  and  axioms  which  can  be  used  to  describe 
domain-specific  formalisms  [14].  The  MetaSlang  grammar  follows  a  functional  style  of 
programming,  which  is  valuable  for  proving  properties  regarding  functions. 

a.  Specs 

“A  specification  is  a  finite  presentation  of  a  theory  in  higher-order  logic” 

[17].  Specifications,  or  specs,  provide  the  means  to  describe  abstract  concepts  of  the 
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problem  domain,  which  is  the  first  step  in  building  an  application.  There  are  three  major 
constituents  of  specs.  The  first  is  types  which  describe  collections  of  values.  The  second 
component  is  operations  which  are  functions  on  these  values.  The  last  constituent  is 
axioms  and  definitions  which  define  the  actions  and  properties  of  types  and  operations. 

In  the  design  of  specifications,  a  combination  of  top-down  and  bottom-up 
approaches  may  be  employed.  The  problem  domain  may  be  broken  down  into  small, 
manageable  parts.  Each  part  is  specified  separately  allowing  one  to  focus  on  small, 
individual  parts  of  the  problem.  A  spec  can  be  extended  by  importing  other  specs  which 
essentially  copies  the  imported  spec  into  the  target  spec  creating  a  larger  and  more 
complex  spec.  Specs  are  also  the  objects  used  in  morphisms  which  define  the  part-of  or 
is-a  relationship  between  two  specs.  Morphisms  allow  for  refinement  of  specs  and 
provide  the  utility  to  take  simple  abstract  specifications  and  refine  them  to  more  concrete, 
complex  specifications  [14].  The  general  form  of  a  spec  definition  is  shown  in  Figure  1. 


TrafficSpec  =  spec 
{body} 

endspec 

Figure  1  Spec  Definition 


b.  Types 

A  type  is  a  syntactic  entity  that  denotes  a  set  of  values.  Types  are 
collections  or  sets  of  objects  and  expressions  that  characterize  those  objects.  Specware 
provides  several  inbuilt  types  in  its  libraries.  These  are  imported  automatically  for  every 
spec  processed  by  Specware.  Users  can  declare  new  types  or  build  or  constitute  new 
types  from  existing  ones,  examples  of  which  are  shown  in  Figure  2. 
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Figure  2  Declaration  of  Types 


c.  Ops  and  Defs 

An  operation,  or  op  in  MetaSlang,  is  a  syntactic  symbol  accompanied  by  a 
Type.  It  is  used  to  describe  instantiations  of  types.  An  op  may  be  used  to  declare  explicit 
types  as  well  as  declare  functions  performing  an  operation  based  on  the  types  given  in  the 
declaration.  Examples  of  op  declarations  are  show  in  Figure  3.  An  op  can  be  either 
monomorphic  or  polymorphic,  as  shown  by  the  examples  light_changes  and  map, 
respecitively. 


Figure  3  Definition  of  light  changes  Operation 


The  behavior  and  constraint  of  an  op  may  be  further  quantified  with  a  def 
(definition).  An  op  definition  corresponds  to  a  previously  declared  op  and  must  match  the 
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signature  of  the  op  declaration.  It  is  possible,  and  recommended,  to  combine  the  op  and 
def  in  one  declaration  using  the  construct  as  show  below  in  Figure  4. 


op  light  changes  (c:  Color) 

:  Color  = 

if  c  =  Read 

then  Green 

else 

if  c  =  Green 

then  Yellow 

else  Red 

Figure  4  Alternative  definition  of  light  changes 


An  op  definition  may  be  considered  a  special  notation  for  an  axiom.  It  is 
able  to  express  the  same  logic  that  an  axiom  might  express;  but  unlike  an  axiom  which  is 
automatically  assumed  to  be  true  and  has  no  proof  obligation,  a  def  may  have  associated 
proof  obligations.  For  precision,  the  use  of  defs  is  encouraged  over  axioms. 

d.  Claims:  Axioms,  Conjectures,  and  Theorems 

Specware  supports  the  three  kinds  of  claims:  axioms,  conjectures,  and 
theorems.  These  are  all  terms  of  Boolean  type.  While  an  axiom  is  assumed  to  be  true 
with  no  proving  obligation,  conjectures  and  theorems  are  claims  that  must  be  proven 
through  the  use  of  op  definitions  and  axioms.  Specware  will  automatically  generate 
conjectures  based  on  op  declarations,  but  the  user  can  also  explicitly  create  conjectures. 
Specware  does  not  really  differentiate  explicit  conjectures  from  theorems,  and  it  handles 
them  in  the  same  way.  Potentially,  issues  may  arise  when  Specware  interfaces  with 
theorem  provers  which  differentiate  the  two  claims.  An  example  of  a  theorem  definition 
is  shown  below  in  Figure  5.  Conjectures  and  axioms  are  specified  in  the  same  way. 


%%  This  theorem  is  trying  to  verify  that 

%%  for  all  traffic  light,  light  change  equal  to  next  state 
theorem  light_ matches  is 
fa(x  :  Traffic-Light) 

light— changes (pro j ect  1 (x) )  =  (project  1 (next_ state (x) ) ) 


Figure  5  Theorem  Definition  in  Traffic  Light  Model 
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e.  Set  and  List 

In  higher-order  logic,  it  is  customary  to  define  a  set  as  a  predicate,  which 
is  true  exactly  for  (i.e.,  for  all  and  only)  the  elements  of  the  set.  Support  for  the  Set 
specification  is  new  in  Specware  version  4.2.5,  and  documentation  on  Set  is  not  yet 
available  in  the  Specware  Language  Manual  at  the  time  of  this  writing.  Unlike  List, 
which  comes  with  a  number  of  helper  operations  to  search  and  manipulate  members  of 
the  List,  Set  is  essentially  a  predicate  which  does  not  allow  enumeration  of  each  of  its 
members.  From  the  comment  inside  the  Set  specification,  it  is  important  to  note  that  Sets 
as  defined  are  useful  only  for  specification  purposes  and  not  for  execution. 

f  Monads 

The  concept  of  Monads  arises  from  category  theory,  about  which  this 
thesis  will  not  go  into  detail.  A  Monad  is  a  kind  of  abstract  data  type  used  to  represent 
computations  (instead  of  data  in  the  domain  model)  in  a  functional  programming 
language  where  a  program  is  written  as  a  set  of  equations  where  the  value  of  an 
expression  depends  only  on  its  free  variables,  and  not  the  order  of  computation.  In  this 
context,  Monads  allows  the  performance  of  “impure”  sequential  operations,  including 
exception  handling,  capturing  of  state  and  state  transitions,  and  output  handling  [18].  Of 
special  relevance  in  the  context  of  the  thesis  regarding  the  construction  of  security 
models  is  the  use  of  Monads  to  represent  state  transitions. 

Programs  written  in  functional  style  can  make  use  of  Monads  to  structure 
procedures  that  include  sequenced  operations  or  to  define  arbitrary  deterministic  control 
flows  (like  handling  concurrency,  continuations  or  exceptions)  [18].  Of  special  relevance 
in  the  construction  of  security  models  is  state  transition. 

The  usual  formation  of  a  Monad  is  known  as  a  Kleisli  triple  and  has  the 
following  components  [18]: 

a.  A  type  constructor  M  that  must  fulfill  several  properties,  which  make 
possible  the  composition  of  functions  that  the  user  values  from  the  Monad 
as  their  arguments  (so-called  monadic  functions).  It  defines  how  the 
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monadic  type  can  be  obtained  from  one  or  more  specific  underlying  types. 
If  M  is  the  name  of  the  Monad  and  t  is  a  data  type,  “M  /”  is  the 
corresponding  type  of  the  Monad. 

b.  A  unit  function  mapping  a  value  in  an  underlying  type  to  a  value  in  the 
corresponding  monadic  type.  The  function  is  usually  called  return  and  has 
the  polymorphic  type  a— >  M  a. 

c.  A  binding  operation  of  polymorphic  type  M  a  —>  (a—>M  b)  — >  Mb.  The 
first  argument  is  a  value  in  a  monadic  type,  the  second  is  a  function  which 
maps  from  the  underlying  type  of  the  first  argument  to  another  monadic 
type,  and  the  result  is  in  that  other  monadic  type.  The  binding  operation 
contains  the  logic  essential  to  execute  the  monadic  functions  or  registered 
callbacks.  In  Spec  ware,  this  function  is  named  monadBind. 

The  explanation  here  is  far  from  complete  and  will  be  left  as  an  exercise 
for  users  to  learn  more  about  Monads.  We  will  leave  with  some  simple  explanation  of 
the  declaration  of  the  Monad  shown  in  Figure  6,  which  is  used  in  most  of  our  models. 
The  type  constructor  is  defined  by  the  first  declaration  of  StateMond  a,  where 
StateMonad  represents  the  name  of  the  Monad  and  a  is  the  underlying  type.  The  unit  or 
return  function  is  represented  in  the  next  statement  and  it  essentially  maps  a  value  of  type 
a  to  StateMonad  a.  Lastly,  monadBind  defines  the  binding  operation  and  is  used 
implicitly  rather  than  explicitly  in  many  Monadic  operations  in  this  thesis. 


type  StateMonad  a  =  State  ->  a  *  State 

op  [a]  return  (x:a) :  StateMonad  a  =  fn  st  ->  (x,  st) 

op  [a,b]  monadBind  (ml:  StateMonad  a,  f  :  a  ->  StateMonad  b) : 

StateMonad  b  = 

fn  st  ->  let  (y,stl)  =  ml  st  in 
f  y  stl 


Figure  6  State  Monard  and  accompanying  monadic  functions 


The  Haskell  programming  language  is  a  functional  language  that  makes 
heavy  use  of  Monads.  The  concept  of  a  Monad  is  not  intuitive  and  is  hard  to  grasp  for 
most  beginners.  It  will  not  be  possible  to  go  into  great  detail  here  and  readers  are  advised 

to  find  out  more  from  the  many  tutorials  available  on  the  web  [18,  19]. 
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The  Specware  User  Manual  contains  only  a  very  brief  description  of 
Monads  (Section  2.6.16)  without  furnishing  any  concrete  example  on  their  usage.  We 
translated  a  simple  Haskell  [19]  example  to  Specware  to  better  understand  the  concept 
and  its  support  in  Specware.  Both  the  Haskell  specification  and  the  corresponding 
Specware  one  can  be  found  in  Appendix  A. 

2.  Specware  to  Isabelle  Translation 

The  specification  in  Specware  can  be  translated  to  Isabelle  Specification  using  the 
command  Ctrl+C  TAB  in  the  Specware  to  Isabelle  Interface. 

A  Specware  definition  may  translate  into  one  of  three  different  kinds  of 
Isabelle  definitions:  defs,  recdefs  and  p  r  i  mr  e  c  s  (primitive 
recursions).  Simple  recursion  on  coproduct  constructors  translates  to 
p  r  i  mr  e  c ,  but  if  the  function  has  multiple  arguments,  only  if  the  function 
is  curried.  Other  recursion  translates  to  r  e  c  d  e  f  which,  in  general, 
requires  a  user-supplied  measure  function  to  prove  termination.  Non¬ 
recursive  functions  are  translated  to  d  e  f  s ,  except  in  some  cases  they  are 
translated  torecdef  s  which  allow  more  pattern  matching  [20]. 

Figure  7  shows  a  sample  Specware  specification,  while  Figure  8  shows  the 
Isabelle  specification  translated  from  the  sample  Specware  specification. 


op  transition:  State  ->  State 

def  transition ( s )  =  (succ  s.l  ,  succ  s.2) 

proof  Isa  [simp]  end-proof 

op  evaluate:  Nat  ->  State 

def  evaluate (n)  =  if  n  =  0  then  (1,0)  else  transition (evaluate (n- 
1)  ) 

proof  Isa  [simp]  end-proof 


Figure  7  Sample  Specware  specification 
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consts  transition  : :  "State  \<Rightarrow>  State" 
defs  transition  def  [simp] : 

"transition  s  \<equiv>  (Sue  (fst  s) ,  Sue  (snd  s) ) " 
theorem  evaluate  Obligation  subtype: 

" \<lbrakk>\<not>  (n  =  0)\<rbrakk>  \<Longrightarrow>  int  n  -  1  \<ge> 
0" 

by  auto 

fun  evaluate  : :  "nat  \<Rightarrow>  State" 
where 

"evaluate  0  =  (1,  0)" 

"evaluate  (Sue  n)  =  transition  (evaluate  n) " 


Figure  8  Isabelle  specification  translated  from  the  sample  Specware  Specification 


3.  Basic  Specware  Operation 


We  can  invoke  the  XEmacs  with  Specware  and  Isabelle  by  running  the 
“Specwarelsabelle”  executable  file  located  in  the  /opt/Kertrel/Specware-4-2-2  directory. 
Figure  9  shows  a  screenshot  of  the  XEmacs  interface,  where  all  the  commands  can  be 
found  in  the  menu  tabs.  Table  1  lists  some  of  the  more  common  XEmacs  and  Specware 
keyboard  commands  that  were  used  in  the  development  of  this  thesis.  The  documentation 
on  using  Specware  can  be  found  in  Specware  4.2  User  Manual  [21]. 


Figure  9  Screenshot  of  XEmacs  for  Specware  and  Isabelle 
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Commands 

Purpose 

CTRL+x  CTRL+F 

XEmacs  command  to  open  a  file 

CTRL+x  CTRL+S 

XEmacs  command  to  save  a  file 

CTRL+x  CTRL+c 

XEmacs  command  to  close  XEmacs 

CTRL+c  p 

Specware  command  to  process  current  file 

CTRL+c  TAB 

Specware  command  to  translate  file  to  Isabelle 

Table  1.  Common  XEmacs  and  Specware  commands 


C.  ISABELLE  PROVING  APPROACHES 
1.  Apply-style  Proofs 

An  apply-style  proof  is  an  interactive  proof  in  higher-order  logic  (HOL)  using 
Isabelle’s  proof  assistant  [22].  Proofing  strategy  can  be  selected  using  the  “apply” 
function  in  Isabelle.  From  the  theorem,  sub-goals  are  derived  and  have  to  be  proved.  The 
thesis  only  lists  a  few  examples  of  the  commands  supported  under  apply-style  proofs. 
More  comprehensive  coverage  can  be  found  on  Isabelle’s  website  [23]. 

a.  apply(auto) 

This  command  will  adopt  the  proof  strategy  called  auto  to  try  to  solve  all 
the  sub-goals  automatically  [22].  Figure  10  shows  a  sample  output  when  Isabelle  is  able 
to  solve  the  sub-goals. 

proof  (prove) :  step  1 
goal: 

No  subgoals ! 

Figure  10  Example  of  sub-goals  being  proven  in  Isabelle 


18 


b.  apply(induct_tac  x) 


This  command  will  apply  a  proof  strategy  called  inducttac  to  perform 
induction  to  the  variable  x  [22],  Figure  11  shows  an  example  of  sub-goals  in  Isabelle 
before  induction  is  applied,  while  Figure  12  shows  an  example  of  induct  tac  being 
applied  to  the  variable  n. 

proof  (prove) :  step  0 

goal  (1  subgoal) : 

1.  proper tyjp  (evaluate  n) 

Figure  1 1  Example  of  sub-goals  in  Isabelle  before  induction  is  applied 


proof  (prove) :  step  1 

goal  (2  subgoals) : 

1.  proper tyjp  (evaluate  0) 

2.  ! !n.  proper tyjp  (evaluate  n)  ==>  proper tyjp  (evaluate  (Sue  n)) 


Figure  12  Example  of  induct  tac  being  applied  to  the  variable  n 


c.  apply(simp  add:  xl  x2) 

This  command  will  apply  a  simplification  proof  strategy  by  adding  xl  and 
x2,  which  are  theory  names,  as  rules  for  it  simplification. 

2.  Structured  Isar  Proofs 

Isar  stands  for  “Intelligiable  semi-automated  reasoning”  and  is  an  extension  of  the 
apply-style  proofs  [24].  Figure  13  shows  a  typical  proof  skeleton  of  Isar  proofs  and 
Figure  14  shows  an  example  of  Isar  proofs  in  Isabelle.  More  comprehensive  coverage  on 
Isar  can  be  found  in  the  Isabelle/Isar  reference  manual  [24]. 
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proof 

assume  "  the-assm  " 

have  * . . . " 

-  intermediate  result 

have  * . . . " 

-  intermediate  result 

show  "  the-concl" 

qed 

Figure  13  Typical  proof  of  skeleton  of  Isar  proofs 


proot  - 

have  new_state:  "snd(MonadBLPSimpleExampleExcepticins _ transition  (a,  MakeKnown)  S)  =  insert  a  S" 

by ( rule_tac  MonadBLP  S imp leExamp leExc  ep ti ons _ tr  ans 1 ti on_MakeKnown_se  cur e ) 

from  al  have  S_secure:  "S  \<subseteq>  MonadBLPSimpleExampleExceptions _ access_secure_p" 

by  (auto  simp  add:  MonadBLPSimpleExampleExceptions _ s e cur e state jp_def) 

with  new_state  a2  'b  =  MakeKnown'  '  MonadBLPSimpleExampleExceptions _ acce3S_securejp  a' 

show  ?thesis  by  (auto  simp  add:  MonadBLPSimpleExampleExceptions _ s e cure state jp_def  mem_def) 

qed 


Figure  14  Example  of  Isar  proofs  in  Isabelle 


D.  SETUP  OF  DEVELOPMENT  ENVIRONMENT  IN  FEDORA  8 

We  are  running  Fedora  8  in  VMware  Workstation  on  a  Windows  Vista  machine. 
The  license  for  the  VMware  Workstation  and  the  image  for  Fedora  8  are  obtained  from 
the  CISR  lab.  The  following  software  are  required  in  Fedora  8  for  the  Specware  and 
Isabelle  development  environment: 

•  XEmacs  version  21.5.28.5 

•  Isabelle  2008  version 

•  Specware  version  4.2.2 

1.  XEmacs  Version  21.5.28.5 

XEmacs  can  be  installed  using  the  yum  command  in  Fedora.  Internet  access  must 
be  available  for  the  Fedora  8  machine  before  yum  can  download  and  install  the  XEmacs. 
Figure  15  shows  the  command  to  install  XEmacs. 

[ root@localhost  -]#  yum  install  xemacs 

Figure  15  yum  command  to  install  XEmacs 
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2. 


Isabelle  2008  Version 


The  following  files  are  required  for  the  Isabelle  2008  installation: 

•  Isabelle2008.tar.gz 

•  ProofGeneral.tar.gz 

•  Polyml_x86-linux.tar.gz 

•  HOL_x86-linux.tar.gz 

Figure  16  shows  the  installation  instruction  for  Isabelle  2008. 

Linux 

Installation  of  Isabelle/HOL  on  Linux  (x86  and  x86_64)  works  by  downloading  and  unpacking  the  relevant  packages. 
Here  the  installation  location  is  /usr/iocai,  but  any  other  directory  works  as  well: 

$  tar  -C  /usr/local  -xzf  Isabelle2008. tar.gz 
$  tar  -C  /usr/local  -xzf  Proof General . tar . gz 
$  tar  -C  /usr/local  -xzf  polyml  xS6-linux . tar . gz 
$  tar  -C  /usr/local  -xzf  HOL  x86-linux. tar . gz 

Normally,  the  default  settings  of  Isabelle  should  be  sufficient  for  invoking  Isabelle  Proof  General  like  this: 

$  /usr/local/Isabelle/bin/Isabelle  -p  xemacs 

Failure  on  this  is  typically  a  problem  with  bad  Emacs  versions;  the  command  line  option  -p  specifies  a  different  Emacs 
executable: 

$  /usr/local/Isabelle/bin/Isabelle  -p  emacs22 

The  X-Symbol  package  is  already  included  in  Proof  General,  but  needs  to  be  enabled  separately;  use  the  -x  command 
line  option,  or  the  Options  menu. 

If  all  fails,  Isabelle  may  also  be  run  without  Proof  General,  via  the  plain  tty  interface  as  follows  (using  CTRL-D  to  exit): 

$  /usr/local/Isabelle/bin/isatool  tty 

The  above  x86  binaries  may  be  also  used  for  64bit  Linux,  but  are  restricted  to  32bit  mode;  native  x86_64  platform 
support  requires  manual  compilation  of  Isabelle. 

Warning:  Pre-packaged  versions  of  Isabelle,  Proof  General,  and  Poly/ML  floating  through  the  Net  as  deb,  rpm,  pore 
etc.  are  often  outdated  and  rarely  work  as  advertized.  Even  XEmacs  is  better  compiled  manually  these  days  -  the 
packages  provided  for  SuSE,  Ubuntu,  and  Debian  are  mostly  broken. 


Figure  16  Installation  Instruction  of  Isabelle  2008  [From  Ref.  [16]] 

3.  Specware  Version  4.2.2 

Execute  ./setuplinux.bin  that  comes  with  the  Specware  version  4.2.2  installation 
package  to  install  the  Specware  software.  Figure  17  shows  a  possible  xcbxlib  error  you 
may  encounter  while  installing  the  Specware  version  4.2.2  in  Fedora  8. 

java:  xeb  xlib.c:50:  xcbxlib  unlock:  Assertion  ' c->xlib. lock'  failed. 


Figure  17  xcb_xlib  error  while  installing  Specware  version  4.2.2  in  Fedora  8 
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A  possible  solution  to  this  error  is  to  update  the  libxcb  to  version  1.0.4  before 
proceeding  with  the  Specware  version  4.2.2  installation.  The  libxcb  can  be  updated  using 
the  command  “yum  update  libxcb.'’'’  At  the  time  of  this  writing,  version  1.0.4  is  not 
available  for  update  in  Fedora  8. 

A  number  of  manual  configurations  are  required  to  get  Specware  version  4.2.2  to 
run  on  Fedora  8  platform.  This  list  of  manual  configuration  is  listed  in  Table  2. 


SN 

Manual  configuration 

Comment 

1 

Delete  the  line  “.  $HERE/F\nd  SBCL  ”  from 
Specware  and  SpecwareShell  in 
/opt/Kestrel/Specware-4-2-2  directory 

SBCL  is  no  longer 
required  by  Specware 

2 

Delete  the  following  lines  from 
“XEmacs_Specware”  in  /opt/Kestrel/Specware-4-2- 
2  directory: 

#  Try  to  find  lisp  executable: 
if  [ -z  ''$LISP”];  then 
for  L  in  /Applications/sbcl/bin/sbcl 
/usr/local/bin/sbcl  "$HOME”/bin/sbcl  /bin/lisp;  do 
if  [ -x  "$L” ] ;  then 

LISP=  "$L  break 

fi 

done 

fi 

if  [  -z  ''SUSP1'];  then 

echo  "Failed  to  $act,  no  LISP  executable  found" 
2>&1 
exit  1 

fi 

iff !  -x  " $LISP "];  then 

echo  "Failed  to  $act,  $LISP  is  not  executable" 
2>&1 
exit  1 

fi 

3 

Comment  out  the  line  “x-symbol-specware”  from 

files. el  in  /opt/Kestrel/Specware-4-2- 

2/Library/IO/Emacs/ 

There  is  a  bug  with  x- 

symbol  and  the  latest 

version  of  xemacs  and  x- 

symbol  is  not  required  to 

run  Specware 
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4 

Include  the  path  to  Isabelle  “/usr/local/Isabelle/bin/” 

To  specify  the  path  to 

to  the  line  “Isabelle  -p  ...”  in  the  file 

Isabelle 

Isabelle_Specware  in  /opt/Kestrel/Specware-4-2-2 

directory 

Table  2.  List  of  Tasks  for  Specware  4.2.2  to  run  in  Fedora  8 
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IV.  SECURITY  MODEL 


A.  MODELING  STRATEGY 

An  iterative  and  incremental  approach  as  shown  in  Figure  18  was  adopted  in 
modeling  in  the  project  as  the  team  is  new  to  both  security  modeling  and  functional 
programming.  After  setting  up  the  initial  environment,  the  team  built  a  simple  Specware 
specification  that  models  a  Traffic  Light  to  get  familiarized  with  Specware  as  described 
in  the  next  section.  Concepts  about  state  and  transition  are  incorporated  in  the  model  as  a 
preparation  for  security  modeling.  The  proof-obligations  are  subsequently  discharged 
and  proven  using  Isabelle. 

The  Traffic  Light  Model  was  expanded  into  a  BLP* -property  model  as  our  first 
attempt  on  security  modeling.  The  team  was  unable  to  successfully  prove  this  first 
simple  model  using  Isabelle,  even  when  the  model  is  trimmed  to  the  bare  minimal  and 
trivial  theorem  is  specified  for  proving.  It  is  found  that  some  understanding  of  the 
intrinsic  of  the  theorem  proving  in  Isabelle  is  essential  to  guide  the  proof  interactively  to 
completion.  The  team  began  the  exploration  of  Monads  at  this  point  as  an  alternative 
representation  of  the  state  changes  as  it  is  suspected  that  the  construct  of  the  state 
changes,  as  is  currently  used  in  the  BLP*-property  model,  may  be  overly  complex, 
making  proving  on  Isabelle  non-trivial.  A  simple  Specware  example  was  created  based 
on  a  widely  available  Haskell  example,  as  in  Appendix  A,  to  explore  the  support  and  use 
of  Monads  on  Specware. 
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Figure  18  Modeling  Approach 


As  a  natural  next  step,  the  BLP  *-model  and  the  Simple  Monad  example  were 
merged  to  obtain  our  first  security  model  specification  (BLP  Model)  with  Monad  using 
Specware.  This  model  was  used  for  the  discussion  and  refined  during  the  team’s  visit  to 
Kestrel.  The  Kestrel  team  attempted  a  proof  of  the  specification  using  Isabelle,  which  is 
documented  in  more  detail  later  in  a  later  section.  After  the  visit,  the  BLP  Model  was 
used  as  a  base  specification  for  a  Least  Privilege  Separation  Kernel  (LPSK). 


B.  SIMPLE  TRAFFIC  LIGHT  MODEL 


Before  specifying  the  security  model,  the  team  explored  representing  traffic  light 
state  changes  in  Specware.  This  Specware  specification  is  subsequently  translated  into  an 
Isabelle  specification  and  proven  in  Isabelle. 

1.  Color  Definition 


There  are  three  colors  in  a  traffic  light:  namely  red,  yellow,  and  green.  The  trivial 
example  described  here  models  simply  how  the  color  changes  in  a  traffic  light  system. 
Figure  19  shows  a  definition  of  type  color  in  Specware,  while  Figure  20  shows  the 
Isabelle  specification  translated  from  the  Specware  specification. 
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%%  Define  that  color  can  be  Red,  Yellow  or  Green 
type  Color  =  |  Red  |  Yellow  |  Green 

Figure  19  Type  Color  definition  in  Spec  ware 


datatype  Color  =  Green 
Red 

Yellow 


Figure  20  Type  Color  definition  in  Isabelle 


2.  Op  light  changes 

Light  changes  is  defined  as  an  op  that  transits  the  current  color  to  the  next  color. 
Figure  21  shows  how  the  op  light  changes  is  defined  in  Specware,  while  Figure  22 
shows  the  translated  specification  in  Isabelle. 


%%  Define  light  changes  function 

%%  The  function  will  return  the  next  color 

%%  based  on  the  inputed  color 

op  light^changes  :  Color  ->  Color 

def  light_changes  (c)  = 

if  c  =  Red  then  Green  else 
if  c  =  Green  then  Yellow  else  Red 


Figure  2 1  Light  changes  definition  in  Specware 


consts  light^changes  : :  "Color  \<Rightarrow>  Color" 
defs  light  changes  def: 

"light  changes  c 

\<equiv>  (if  c  =  Red  then 
Green 
else 

if  c  =  Green  then  Yellow  else  Red)  " 


Figure  22  Light  changes  definition  in  Isabelle 


3.  Traffic  Light  as  a  List  of  Colors 

The  traffic  light  can  be  modeled  as  a  color  sequence  (represented  in  a  list)  with 


transition  occurring  from  each  sequence  element  to  the  next.  Figure  23  shows  how  this 
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transition  is  defined.  To  test  out  proving  on  Isabelle,  a  trivial  theorem  was  formulated. 
Two  axioms  are  defined  and  used  in  the  proving  of  the  theorem. 


%%  define  traffic  light  as  a  list 
type  Traf f ic_ Light  =  List  Color 

%%  Axiom  to  state  traffic  light  list  is  not  empty  and 
%%  traffic  light  list  starts  with  Yellow 

axiom  aO  is 

fa(x  :  Traf f ic_Light) 

~ (null  x)  &&  (hd  x  =  Yellow) 

%%  Axiom  to  state  the  state  changes  in  the  traffic  light  list 

axiom  a2  is 

fa  (  x  :  Traffic  Light,  y  :  Integer) 

(if  y>=0  &&  y  <  (length  x  -1)  then  (*  y  is  valid  index  *) 
nth(x,  y+l)=  light  changes (nth (x,  y) ) 

else 

true) 

%%  This  Theorem  states  that 

%%  for  all  traffic  light  lists  with  any  number  of  state  changes 
%%  the  sequence  of  light  changes  is  correct 
theorem  light— matches  is 

(fa  (  x  :  Traffic-Light,  y:  Integer) 

( (y  >=  0  &&  y  <  length  x  -  1)  =>  light  changes  (nth(x,y))  = 
nth (x, y+1 ) ) ) 
proof  Isa  [simp] 
using  aO  a2 
apply (auto) 
end-proof 


Figure  23  Specware  specification  representing  the  transition  from  color  to  color  in 

list  and  a  trivial  theorem 

The  Specware  specification  can  be  translated  to  Isabelle  specification  by  issuing 
the  CTRL+C  TAB  command  in  Specware  specification  window.  Figure  24  shows  the 
translated  Isabelle  specification 
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types  Traffic  Light  =  "Color  list" 

consts  light  changes  : :  "Color  \<Rightarrow>  Color" 
defs  light  changes  def: 

"light  changes  c 

\<equiv>  (if  c  =  Red  then 
Green 
else 

if  c  =  Green  then  Yellow  else  Red)  " 

axioms  aO : 

"\<not>  (null  x)  \<and>  hd  x  =  Yellow" 
theorem  a2_0bligation  subtype: 

"\<lbrakk> (y : : int)  \<ge>  0;  y  <  int  (length  x)  -  l\<rbrakk> 
\<Longrightarrow>  y  +  1  \<ge>  0" 
by  auto 

theorem  a2  Obligation  subtypeO: 

"\<lbrakk> (y : : int)  \<ge>  0; 
y  <  int  (length  x)  -  1; 

y  +  1  \<ge>  0\<rbrakk>  \<Longrightarrow>  y  +  1  <  int  (length  x) " 
by  auto 

theorem  a2  Obligation  subtypel: 

"\<lbrakk> (y : : int)  <  int  (length  x)  -  1;  y  \<ge>  0\<rbrakk> 
\<Longrightarrow> 

y  <  int  (length  x) " 
by  auto 
axioms  a2 : 

"if  y  \<ge>  0  \<and>  y  <  int  (length  x)  -  1  then 
x  !  nat  (y  +  1)  =  light  changes  (x  !  nat  y) 
else 
True" 

theorem  light  matches  [simp] : 

"\<lbrakk>y  \<ge>  0;  y  <  int  (length  x)  -  l\<rbrakk> 
\<Longrightarrow> 

light  changes  (x  !  nat  y)  =  x  !  nat  (y  +  1)" 
using  aO  a2 
apply (auto) 

done 


Figure  24  Translated  Isabelle  specification  for  transition  from  color  to  color  in  list 

and  the  trivial  theorem 

Proving  can  be  done  in  Isabelle  by  using  the  Retract,  Undo,  Next,  Use  or  Goto 
commands  as  shown  in  Figure  25.  The  Retract  command  will  undo  all  the  proof  steps  and 
return  to  the  beginning  of  the  Specification.  The  Undo  command  will  undo  the  current 
statement.  The  Next  command  will  “execute”  the  current  statement.  The  Use  command 
will  execute  all  the  statements  till  the  end  of  the  specification,  and  the  Goto  command 
will  execute  up  to  the  current  statement.  Figure  26  shows  an  example  of  a 
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counterexample  found  before  axioms  are  being  applied.  After  the  axioms  are  applied  in 
the  proof,  Isabelle  was  only  left  with  one  subgoal  to  prove  as  shown  in  Figure  27.  Figure 
28  shows  the  end  result  of  the  proof  of  the  theorem. 


File  .Edit  View  Qnds  Tools  Options  Buffers  A+  A+ Options  Proof- General  Isabelle 


Of) 

CD 

State 

Context 

ListSpec_TrafficLi3tSp.  .  .  | Scratch.  thy| _ 

%%  This  is  a  simple  Specware  specification  that  modelled 
%%  a  traffic  light  state  changing  process  using  list 


TrafficListSpec  =  spec 

%%  Define  that  color  can  be  Red,  Yellow  or  Green 
type  Color  =  |  Red  |  Yellow  |  Green 


Figure  25  Screenshot  of  Isabelle  command  menu 


proof  (prove) :  step  0 
goal  (1  subgoal) : 

1.  [|  0  <=  y;  y  <  int  (length  x)  -  1  |] 

==>  light_changes  (x  !  nat  y)  =  x  !  nat  (y  +  1) 

Counterexample  found: 

x  =  [Red,  Red] 
y  =  0 

else 
True  " 

theorem  light_matches  [simp] : 

"\<  Ubrakk>y  \<ge>  0;  y  <  int  (length  x)  -  l\<rbrakk>  \<Longrightarrow> 
light_changes  (x  !  nat  y)  =  x  !  nat  (y  +  1) " 
using  aO  a2/vM 
apply  (auto)  '"'M 

done 

end| 

Figure  26  A  counter  example  is  found  by  Isabelle  before  using  the  two  axioms 
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proof  (prove) :  step  1 
using  thi.3 : 

~  null  ?x  &  hd  ?x  =  Yellow 

if  0  <=  ?y  &  ?y  <  int  (length  ?x)  -  1 

then  ?x  !  nat  (?y  +  1)  =  light_changes  (?x  !  nat  ?y)  else  True 
goal  (1  subgoal) : 

1  [|  0  <=  y;  y  <  int  (length  x)  -  1  |] 

==>  light_changes  (x  !  nat  y)  =  x  !  nat  (y  +  1) 

else 

True  " 

theorem  light_matches  [simp] : 

"\<lbrakk>y  \<ge>  0;  y  <  int  (length  x)  -  l\<rbrakk>  \<Longrightarrow> 
light_changes  (x  !  nat  y)  =  x  !  nat  (y  +  1) " 
using  aO  a2''M| 
apply  (auto) 

done 

end 

Figure  27  After  the  two  axioms  are  applied,  Isabelle  only  need  to  prove  one  subgoal 


Proof:  The  theorem  lightmatches  is  proved  using  apply(auto) 


theorem 

light_matches : 

[ |  0  <=  ?y ;  ?y  <  int  (length  ?x)  -  1  |] 

==>  light_changes  (?x  !  nat  ?y)  =  ?x  !  nat  (?y  +  1) 


else 
True " 

theorem  light_matches  [simp] : 

"\<lbrakk>y  \<ge>  0;  y  <  int  (length  x)  -  l\<rbrakk>  \<Longrightarrow> 
light_changes  (x  !  nat  y)  =  x  !  nat  (y  +  1) " 
using  aO  a2''M 
apply (auto) 

done 

end 


Figure  28  Isabelle  proof  for  theorem  light  matches  for  traffic  light  represented  using 

list  of  color 


4,  Traffic  Light  as  a  State  Tuple 


The  traffic  light  can  alternatively  be  modeled  as  a  tuple  representing  the  current 
state.  Each  tuple  is  comprised  of  a  color  and  a  counter  indicating  the  number  of 
transitions  which  have  occurred  from  initialization.  Figure  29  shows  how  this  state 
change  transition  is  represented  in  Specware.  The  op  next_state  defines  the  state 
transition,  the  op  runjraffic  executes  the  state  transition  the  inputted  number  of  steps, 
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and  the  theorem  light  matches  is  formulated  just  as  a  simple  illustration  of  the  use  of 
apply(simp  add:  ...)  in  Isabelle.  Figure  30  shows  the  translated  Isabelle  specification  of 
this  model. 


%%  Define  that  Traffic  light  is  a  color  and  integer  tuple 
%%  The  integer  act  as  a  counter  to  indicate  the  number 
%%  of  state  changes 

type  Traf f ic_Light  =  Color  *  Integer 
%%  Define  next  state  function 

%%  This  basically  is  representing  a  state  transition  process 
%%  where  the  light  will  transit  to  the  next  light  and 
%%  the  counter  will  increment  by  one 
op  next_state  :  Traf f ic_Light  ->  Traffic  Light 
def  next_state (x)  =  ( light_changes (pro j ect  1 (x) ) , ((project 
2 (x) ) +1 ) ) 

%%  Define  run  traffic  function 

%%  This  function  will  execute  the  inputed  natural  number 
%%  count  of  state  transition 
op  run  traffic  :  Nat  ->  Traffic  Light 
def  runtraffic(n)  =  if  n  <=  0  then  (Yellow, 0)  else 
next  state (run  traf f ic (n-1 ) ) 

%%  This  theorem  is  trying  to  verify  that 

%%  for  all  traffic  light,  light  change  is  equal  to  next  state 
theorem  light_matches  is 
fa(x  :  Traffic  Light) 

light_changes (pro j ect  1  (x) )  =  (project  1 (next_state (x) ) ) 

proof  Isa 

apply (simp  add:  light  changes  def  next  state  def) 

end-proof 


Figure  29  Traffic  light  modeled  as  a  tuple  of  color  and  the  number  of  state  changes 
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types  Traffic  Light  =  "Color  \<times>  int" 

consts  light^changes  : :  "Color  \<Rightarrow>  Color" 

defs  light  changes  def: 

"light  changes  c 

\<equiv>  (if  c  =  Red  then 
Green 
else 

if  c  =  Green  then  Yellow  else  Red)  " 
consts  next  state  : :  "Traf f ic_Light  \<Rightarrow>  Traffic  Light" 
defs  next_state_def : 

"next  state  x  \<equiv>  (light  changes  (fst  x)  ,  snd  x  +  1)" 
theorem  run  traffic  Obligation  subsort: 

" \<lbrakk>\<not>  (n  \<le>  0) \<rbrakk>  \<Longrightarrow>  int  n  -  1 
\<ge>  0" 
by  auto 

consts  run  traffic  : :  "nat  \<Rightarrow>  Traffic  Light" 
recdef  run  traffic  "measure  size" 

"run  traffic  n 

=  (if  n  \<le>  0  then 
(Yellow,  0) 
else 

next_state  (run_traffic  (n  -  1)))" 
theorem  light  matches: 

"light  changes  (fst  x)  =  fst  (next  state  x)  " 

apply (simp  add:  light^changes  def  next  state  def) 
done 


Figure  30  Translated  Isabelle  specification  for  the  traffic  light  modeled  as  a  tuple  of 

color  and  the  number  of  state  changes 


5.  Discussion  and  Lessons  Learned 

The  state  tuple  provides  a  concise  way  of  representing  state  and  tracking  changes. 
The  two  representations  are,  however,  observed  to  have  similar  effects  and  the  List  model 
is  adopted  in  the  subsequent  Simple  BLP  * -property  example  to  harness  the  inbuilt 
support  of  Specware  for  List  for  easy  manipulation  of  its  elements.  The  traffic  light 
model  shows  the  team’s  first  attempt  at  modeling  the  notion  of  a  state  which  essentially  is 
the  color  of  the  light  and  the  state  change  function.  A  simple  theorem  labelled 
light  change  has  been  fonnulated  as  an  illustration.  Its  proof  obligation  is  discharged  for 
proving  in  Isabelle  via  the  Specware  to  the  Isabelle  Interface  and  proven  successfully. 
The  translation  looks  simple  but  in  fact  took  substantial  effort  as  the  team  was  new  to 
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Specware,  Isabelle  and  also  to  the  Specware  to  Isabelle  Interface.  Whenever  a  problem 
was  encountered  in  the  proofing  of  the  outputted  Isabelle  specification,  it  was  not  easy  to 
determine  if  the  problem  lies  in  our  model  or  in  the  Isabelle-Specware  translation.  For 
example,  a  few  of  the  problems  were  related  to  the  use  of  the  Nat  and  Int  types  due  to  the 
additional  obligations  generated  for  the  fonner  type.  As  the  team  worked  with  the  model 
and  proofing,  we  realized  increasingly  that  a  working  knowledge  of  theorem  provers  and 
Isabelle  would  be  needed  to  guide  the  proof  and  troubleshoot  any  problem  that  may  arise 
due  to  the  translation.  Having  got  a  first  taste  of  Specware  and  Isabelle,  the  team 
proceeded  to  build  the  first  security  model  to  model  BLP  * -property  in  Specware. 

C.  MODELING  BLP  ^-PROPERTY  IN  SPECWARE 

1.  Model  Description 

We  are  creating  a  security  model  based  on  the  Security  Domain  Model  [25].  This 
model  consists  of  two  inputs,  a  memory  and  a  list  of  program  statements  as  shown  in 
Figure  3 1 . 


ComputerSystem 


List  of  variables 


_ y  i 

List  of  high 
inputs 

- * 

List  of 

Main  Program 

s — 

Program 

List  of  low 

ja 

Statement 

inputs 

Figure  3 1  Computer  system  block  diagram 

The  high  inputs  represent  input  with  high  label,  while  the  low  input  represent 
input  with  low  label.  The  label  of  the  variable  takes  the  label  of  the  source,  which  can  be 
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high  input,  low  input,  another  variable,  or  a  constant  (low  label).  The  types  of  statements 
supported  in  this  model  are  read,  write  and  assign.  The  security  property  the  model  is 
checking  is  * -property  (no  write  down)  of  BLP. 


2.  Specware  Model 

The  Specware  model  is  being  broken  down  into  the  following  Specware 
Specifications: 

•  TypeDefSpec.sw  -  the  specification  file  where  all  the  required  type 
definitions  is  located. 

•  MemorySpec.sw  -  the  specification  file  where  all  the  functions  that 
manipulate  the  memory  state  (variable,  high  input,  and  low  input)  is 
located. 

•  StatementSpec.sw  -  the  specification  where  all  the  functions  that 
FileSystemSpec.sw  required  to  execute  the  statement  (assign,  read,  and 
write). 

•  InitSpec  -  the  specification  where  the  initial  state  of  the  system  is  being 
defined. 

•  FileSystemSpec.sw  -  the  main  specification  of  the  model,  which  includes 
the  state  transition,  property  check  and  the  theorem. 

a.  Type  Definition  (TypeDefSpec.sw) 

All  the  required  type  declarations  by  the  model  are  placed  in  the 
TypeDefSpec.sw.  For  easy  readability,  some  initial  types  are  declared  as  shown  in  Figure 
32. 

%%  Initial  type  declaration 

type  Name  =  String 

type  Value  =  Integer 

type  Index  =  Nat 

type  ProgCounter  =  Nat 

Figure  32  Initial  type  declaration 
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The  label  is  declared  as  high  or  low  as  shown  in  Figure  33. 


type  Label  =  |  High  |  Low 


Figure  33  Label  type  declaration 


Variables  are  declared  as  a  list  of  tuples  as  shown  in  Figure  34.  The  tuple 
consists  of  Name,  Value,  and  Label. 


%%  Variable  declaration 

type  Variable  =  Name  *  Value  *  Label 

type  Variables  =  List  Variable 

Figure  34  Variables  type  declaration 


Input  is  declared  as  a  tuple  as  shown  in  Figure  35.  The  tuple  consists  of  a 
list  of  values  and  an  index.  The  index  will  indicate  the  next  value  to  be  read  from  the 
input  list. 


%%  Input  declaration 

type  Input  =  (List  Value)  *  Index 


Figure  35  Input  type  declaration 


Types  of  statements  that  are  supported  in  this  model  include  ReadLow, 
ReadHigh,  WriteLow,  WriteHigh,  Assignl,  Assign2,  and  Stop  as  shown  in  Figure  36. 
Assign  is  being  represented  by  Assignl  and  Assign 2,  where  Assignl  represents  assigning 
a  variable  to  another  variable,  and  Assign2  represents  assigning  a  constant  to  a  variable. 


%%  Statement  declaration 

%%  assignl  -  variable  name  =  variable  name,  eg  a  =  b 
%%  assign2  -  variable  name  =  value,  eg  a  =  5 

type  TypeOfStmt  =  |  ReadLow  |  ReadHigh  |  WriteLow  |  WriteHigh 

Assignl  |  Assign2  |  Stop 


Figure  36  Type  of  statement  type  declaration 
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A  Statement  is  being  declared  as  a  tuple  as  shown  in  Figure  37.  Initially, 
the  team  intended  to  represent  the  statement  with  six  elements,  but  the  Specware 
translator  only  allowed  the  maximum  of  five  elements  in  a  tuple.  Therefore,  we  created 
an  extra  tuple  called  NextProgCounter  in  Stmt.  The  first  ProgCounter  indicates  the  index 
of  the  next  statement  to  execute,  and  the  second  ProgCounter  is  reserved  for  future 
implementation  of  if-then-else  statements.  Sample  code  on  how  if-then-else  statements 
can  be  included  in  the  model  is  available  as  part  of  Appendix  B. 


%%  Left-hand  part 
type  LHP  =  Name 

%%  Right-hand  part 

type  RHP  =  |  VarName  String  |  VarValue  Integer 

%%  used  to  indicate  the  index  for  next  statement  to  execute 
%%  normally  first  ProgCounter  is  used. 

%%  but  when  conditional  statement  like  if-then-else  is  used 
%%  the  first  ProgCounter  is  for  positive  evaluation  in  if  and 
%%  the  second  ProgCounter  is  for  the  negative  evaluation  in  else 
type  NextProgCounter  =  ProgCounter  *  ProgCounter 

%%  Statement  definition 

type  Stmt  =  Name  *  TypeOfStmt  *  LHP  *  RHP  *  NextProgCounter 


Figure  37  Statement  type  declaration 


Finally,  the  Program,  Memory  State,  and  the  SystemState  are  declared  as 
shown  in  Figure  38. 


%%  Program  declaration 

type  Program  =  (List  Stmt)  *  ProgCounter 

%%  Memory  State  declaration-  Variables,  Low  Input,  High  Input 
type  MemoryState  =  Variables  *  Input  *  Input 

%%  System  state  declaration  -  Variable,  Low  Input,  High  Input, 
Program 

type  SystemState  =  Variables  *  Input  *  Input  *  Program 


Figure  38  Program,  Memory  State,  and  System  State  type  declaration 


37 


b.  Memory  Manipulation  (Mem orySpec. s \v) 


All  the  functions  to  manipulate  the  memory  state  of  the  model  are  located 
in  the  MemorySpec.sw.  These  functions  include  readjow,  read  high,  find  variable,  and 
update_variable.  They  are  used  by  functions  in  StatementSpec.sw. 

The  readjow  definition  will  read  the  next  input  from  low  input,  increase 
the  index  of  low  input,  and  return  the  new  memory  state  and  the  read  value  from  low 
input.  The  definition  is  shown  in  Figure  39. 


%%  Read  from  the  low  input  list  based  on  the  current  index 
%%  Increment  Index 
%%  Returns  the  value  read 

op  read  low  :  MemoryState  ->  MemoryStateValueTuple 
def  read_low  (mem^state)  = 

let  read  value  =  read  inputLow (mem  state)  in 
let  updated_input_stream  = 

(mem  state. 2.1,  succ (mem  state. 2. 2))  in 
let  updated_memory  = 

(mem_state . 1 ,  updated  input  stream,  mem  state. 3)  in 
(updated_memory,  read_value) 
proof  Isa  [simp]  end-proof 


Figure  39  op  readjow  definition 


The  read  high  definition  is  similar  to  readjow  definition  except  that  it 
will  read  from  the  high  input  and  return  the  value  from  high  input. 

The  findvariable  definition  will  find  the  variable  from  the  variable  list 
and  return  the  variable  tuple.  The  return  type  is  Option  Variable,  which  mean  that  it  will 
return  the  tuple  if  it  is  found,  if  not  “None”  will  be  returned.  Figure  40  shows  the  op 
find_variable  definition. 


%%  Find  the  variable  from  the  variable  list 
%%  based  on  variable  name  and  return  the  variable 
op  find  variable  :  Name  *  MemoryState  ->  Option  Variable 
def  find  variable (var  name,  mem  state)  = 

find  (fn  i  ->  compare (var  name,  i.l)  =  Equal)  (mem  state. 1) 
proof  Isa  [simp]  end-proof 


Figure  40  op  find  variable  definition 
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The  update _variable  definition  updates  the  variable  according  to  the 
parameter  passed  in  to  the  definition.  Figure  41  shows  the  op  update  variable  definition. 


%%  Update  the  varibale  with  the  new  value 

op  update  variable  :  Name  *  Value  *  Label  *  MemoryState  -> 
MemoryState 

def  update  variable (var  name,  var  value,  var  Label,  mem  state)  = 
let  new  var  =  insert ( (var  name,  var  value,  var  Label), 
filter  (fn  i  ->  compare (var  name,  i.l)  ~=  Equal) 

(mem  state. 1))  in 

(new  var,  mem  state. 2,  mem  state. 3) 
proof  Isa  [simp]  end-proof 


Figure  41  op  update  variable  definition 


c.  Support  Functions  for  Statement  Execution  (StatementSpec.sw) 

All  the  support  functions  for  statement  execution  are  located  in 
StatemaentSpec.sw.  These  include  readjow 'June,  readjiigh June,  assignl June, 
assign2  June,  and  get_var_value.  They  are  used  by  the  FileSystemSpec.sw. 

The  read  low  June  function  calls  the  read  low  from  MemorySpec.sw  to 
read  a  value  from  low  input  and  updates  the  read  value  into  the  specified  variable 
together  with  a  Low  label  (indicating  that  the  value  is  from  low  input).  Figure  42  shows 
the  definition  of  readjow  June. 


%%  function  to  read  from  low  input  and  assign  to  variable 
%%  specified  by  LHP 

op  read  low  func  :  LHP  *  MemoryState  ->  MemoryState 
def  read  low  func  (var  name,  mem  state)  = 

let  read  value  =  (read  low (mem  state)) .2  in 

update  variable (var  name,  read  value.  Low,  mem  state) 
proof  Isa  [simp]  end-proof 


Figure  42  op  readjow  June  definition 


The  read  high  June  definition  is  similar  to  the  readjow  June  except  that 
it  is  reading  from  high  input,  and  hence  the  label  is  High. 

The  assignl  June  definition  uses  the  case  method  to  extract  the  variable 
name  from  RHP  as  shown  in  Figure  43  and  calls  find_variable  in  MemorySpec.sw  to  get 

39 


the  variable  tuple  stated  by  the  RHP.  If  the  variable  is  in  the  variable  list,  the  keyword 
“Some”  can  be  used  to  retrieve  the  tuple  and  update  the  variable  using  update  variable  in 
MemorySpec.sw.  “None”  indicates  that  the  variable  was  not  found  and  the  definition  will 
just  return  the  current  memory  state. 


%%  function  to  assign  a  value  of  a  variable  to  a  variable  (LHP) 
op  assignl  func  :  LHP  *  RHP  *  MemoryState  ->  MemoryState 
def  assignl  func(l,  r,  mem  state)  = 

%%  find  out  the  value  of  the  variable  specified  by  RHP 
%%  then  assign  the  value  to  LHP, 

%%  if  not  variable  not  found  -  just  do  nothing 
case  r  of 

VarName  v  -> 

let  x  =  find  variable (v, mem  state)  in 

case  x  of 

Some  var  ->  update  variable  (1,  var.2,  var.3. 


None  ->  mem  state 
proof  Isa  [simp]  end-proof 


mem  state) 


Figure  43  op  assignl  June  definition 


The  assign2  June  definition  uses  the  case  method  to  extract  the  value  from 
RHP  as  shown  in  Figure  44  and  updates  the  variable  using  update  variable  in 
MemorySpec.sw  accordingly. 


%%  function  to  assign  an  integer  (RHP)  to  a  variable  (LHP) 
op  assign2  func  :  LHP  *  RHP  *  MemoryState  ->  MemoryState 
def  assign2  func(l,  r,  mem  state)  = 

%%  assign  the  value  from  RHP  to  LHP, 

case  r  of 

VarValue  v  -> 

update  variable  (1,  v.  Low,  mem  state) 
proof  Isa  [simp]  end-proof 


Figure  44  op  as  sign  2  June  definition 


The  get_var_value  definition  uses  the  find_yariable  in  MemorySpec.sw  to 
get  the  value  of  the  variable;  if  the  variable  is  not  found,  zero  will  be  returned.  Figure  45 
shows  the  definition  of  get_var_va/ue. 
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%%  function  to  get  value  from  variable  name, 

%%  if  variable  not  found,  zero  will  be  returned  by  default 
op  get  var  value  :  Name  *  MemoryState  ->  Value 
def  get_var_value (n,mem_state)  = 

let  x  =  find  variable (n,  mem  state)  in 
case  x  of 

Some  v  ->  v. 2 

%%  default  to  0  if  not  found 

None  ->  0 

proof  Isa  [simp]  end-proof 


Figure  45  op  get_var_value  definition 


d.  Initialize  Specification  (InitSpec.sw) 

The  initialize  specification  contains  the  initial _state  definition  which  can 
be  replaced  subsequently  by  any  program  pseudo  code  of  the  same  syntax.  Figure  46 
shows  the  sample  initial  state  definition  used  in  this  thesis. 


op  initial_state  :  SystemState 
def  initial_state  :  SystemState  = 
%%  init  Variable 
(  [ ( "x" , 0 ,  Low),  ( "y" , 0 ,  Low)], 
%%  init  low  input 
(  [2,7, 18] ,0) , 

%%  init  high  input 
(  [4, 10,35] ,0) , 

%%  init  program 


"s0". 

Assign2 , 

"x". 

VarValue 

5, 

\ — 1 

\ — 1 

["si". 

ReadLow, 

"y". 

VarValue 

0, 

(2,  2)  )  , 

I"s2", 

Assignl , 

"x". 

Var Name 

"y". 

(3,  3)  )  , 

!"s3". 

ReadHigh, 

"y". 

VarValue 

o. 

(4,  4)), 

[  " s4 " , 

WriteHigh, 

"y". 

VarValue 

o. 

(5,  5)  )  , 

;  "s5" , 

WriteHigh, 

"x". 

VarValue 

0, 

(6,  6)  )  , 

"s6" , 

Stop, 

II  II 

r 

VarValue 

0, 

(6,  6))] 

0)  ) 

proof  Isa  [simp]  end-proof 


Figure  46  Sample  op  initial  state  definition 


e.  Main  Specification  ( FileSystemSpec.sw j 

The  main  specification  of  the  model  contains  the  definition  state  transition, 
property  checks  and  the  theorems.  Figure  47  shows  part  of  the  transition  definition,  the 
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full  definition  is  available  in  the  Appendix  B.  The  transition  definition  will  go  to  the 
statement  specified  by  the  ProgCounter  and,  based  on  the  TypeOfStmt,  execute  the 
different  if-then-else  branches.  After  executing  the  statement,  transition  will  return  the 
next  system  state.  WriteLow  and  WriteHigh  statements  are  handled  in  the  transition,  but 
since  there  is  no  output  in  this  model,  it  will  just  transit  to  the  next  state. 


%%  system  state  transition 

op  transition  :  SystemState  ->  SystemState 
def  transition  (s)  = 

%%  as  nth  will  be  used,  it  is  required  to  confirm  the  length 
%%  of  the  list  before  proceeding,  else  Isabelle 
if  (length  s.4.1)  >  s.4.2  then 
let  vars  =  s . 1  in 
let  inputLow  =  s.2  in 
let  inputHigh  =  s . 3  in 
let  prog  =  s . 4  in 

let  stmt  =  nth  (prog.l,  prog. 2)  in 
%%  Handle  read  low  statement 
if  stmt. 2  =  ReadLow  then 

%%  Read  from  low  input  and  assign  to  variable 
%%  specified  by  LHS 

let  new  mem  =  read  low  func(stmt.3,  (vars,  inputLow, 

inputHigh) )  in 

%%  Update  prog  state  -  assign  next  program  counter 
let  new  prog  =  (prog.l,  stmt. 5.1)  in 

(new  mem.l,  new  mem. 2,  new  mem. 3,  new  prog) 


%%  by  defualt  return  the  current  state  for  unknown  statement 

else  s 

proof  Isa  [simp]  end-proof 


Figure  47  Partial  op  transition  definition 

The  BLP  * -property  is  defined  in  the  property  definition  shown  in  Figure 
48.  Only  if  the  statement  is  doing  a  WriteLow  and  the  label  of  the  variable  to  be  written 
to  Low  is  High  then  the  definition  will  return  a  false. 
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%%  check  the  system  state  for  writing  high  to  low  (BLP  *-property) 
op  property?  :  SystemState  ->  Boolean 
def  property? (s)  = 

%%  as  nth  will  be  used,  it  is  required  to  confirm  the  length 
%%  of  the  list  before  proceeding,  else  Isabelle 
if  ((length  s.4.1)  >  s.4.2)  then 
let  stmt  =  nth (s . 4 . 1 , s . 4 . 2 )  b 

%%  will  return  false  only  if  the  statement  is  writelow 
%%  and  the  label  of  the  variable  is  high 
if  (stmt. 2  =  WriteLow)  && 

(exists(fn  i  ->  ((i.l  =  stmt. 3)  && 

(i.3  =  High)))  (s.l))  then 
false 
else 
true 

else 

true 

proof  Isa  [simp]  end-proof 


Figure  48  op  property  definition 

The  evaluate  definition  is  a  recursive  function  which  initializes  the  system 
state  and  does  a  number  of  transitions  depending  on  the  input  nature  number.  Figure  49 
shows  the  definition  of  evaluate. 


%%  This  function  will  run  n  number  of  line  of  the  program 
%%  The  function  is  of  recursive  nature,  where  it  will  recursively 
%%  call  itself  until  n  =  0,  and  the  systemstate  will  be 
%%  iniitalize  to  the  initial  state,  subsequently  transition 
%%  will  happen  until  the  initial  n  value 
op  evaluate  :  Nat  ->  SystemState 
def  evaluate (n)  = 
if  n  =  0  then 
initial  state 
else 

transition (evaluate (n-1)  ) 
proof  Isa  [simp]  end-proof 


Figure  49  op  evaluate  definition 

The  system  secure  theorem  shown  in  Figure  50  verifies  whether  or  not  the 
program  loaded  through  the  initial  state  in  InitSpec.sw  violates  the  BLP  * -property 
defined  by  the  property  definition.  We  are  not  able  to  complete  the  proving  of  this 
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theorem  using  Isabelle,  as  it  requires  an  in-depth  understanding  of  the  intrinsic  of  the 
Isabelle  theorem  proofing  process.  In  its  place  we  created  a  theorem  shown  in  Figure  51 
to  illustrate  the  proving  of  a  trivial  theorem  in  Isabelle. 


%%  This  theorem  is  evaluate  whether  the  input  program  is 
secure 

theorem  system  secure  is 
fa(n  :  Nat) 

property? (evaluate (n) ) 

%%  This  proof  could  not  be  complete  in  Isabelle 
%%  It  require  an  more  in  depth  understanding  of 
%%  Isabelle 
proof  Isa  [simp] 

apply (induct_tac  n) 
apply (auto  simp  add:  Let_def) 
end-proof 


Figure  50  theorem  system secure  definition 


%%  This  function  checks  whether  the  program  counter 
%%  is  greater  than  0 

op  pcProperty?  :  SystemState  ->  Boolean 
def  pcProperty? ( s )  = 

if  ((length  s.4.1)  >  0)  then 
true 
else 
false 

proof  Isa  [simp]  end-proof 

%%  This  trivial  theorem  will  confirm  that  Prog  counter 
%%  will  remain  greater  than  0 
theorem  pc  ok  is 
fa(n  :  Nat) 

pcProperty? (evaluate (n)  ) 
proof  Isa  [simp] 

apply (induct_tac  n) 
apply (auto  simp  add:  Let_def) 
end-proof 


Figure  5 1  op  pcProperty  and  theorem  pc_ok  definition 


3.  Discussion  and  Lessons  Learned 

Many  valuable  lessons  on  the  use  of  Specware  and  Isabelle  were  learned  in  the 
process  of  building  this  model.  We  learned  that  instead  of  using  the  simp  add  command 
in  Isabelle,  we  can  add  proof  Isa  [simp]  end-proof  at  the  end  of  each  op  definition.  This 
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will  instruct  Isabelle  to  add  the  op  definition  after  it  is  being  proved  to  the  list  of 
simplification  rules,  which  can  be  used  for  proofing  of  other  op  definition  or  theorem.  All 
the  codes  listed  in  Figure  39  through  Figure  51  used  this  proof  Isa  [simp]  end-proof 
approach.  Figure  52  shows  an  example  of  theorem  pcok  definition  using  simp  add 
command.  The  pcProperty?  predicate  is  converted  to  to  pcProperty_p_def,  where  ?  is 
converted  to  _p  and  _def  is  added  to  all  op  during  the  translation  by  Specware. 


theorem  pc  ok  is 
fa(n  :  Nat) 

pcProperty? (evaluate (n) ) 
proof  Isa  [simp] 

apply (induct_tac  n) 

apply (auto  simp  add:  Let_def  pcProperty_p_def  evaluate_def ) 
end-proof 


Figure  52  Example  of  theorem  pc  ok  using  simp  add  command 


If  we  want  to  translate  the  Specware  specification  to  the  Isabelle  specification,  the 
maximum  number  of  elements  allowed  in  any  tuple  ( type  product)  is  five.  Specware  has 
added  this  restriction  by  design  since  by  having  too  many  elements  in  the  tuple,  the 
specification  may  become  unreadable.  Kestrel  recommended  the  use  of  a  record  type 
instead  of  the  tuple.  This  is  one  of  a  few  undocumented  facts  about  the  Specware  to 
Isabelle  Interface  that  the  team  encountered  and  valuable  time  was  spent  in 
troubleshooting  just  to  isolate  the  problem.  It  was  particularly  painful  that  no  error  was 
generated  during  the  translation  process. 

Problems  may  be  faced  in  proving  of  the  translated  Isabelle  specification  if  we 
were  to  use  “+”  or  to  increase  or  decrease  a  natural  number.  The  correct  way  is  to  use 
a  built-in  function  in  Metaslang  like  succ  or  pred  for  the  increment  or  decrement  of  a 
natural  number. 

The  use  of  the  “ case  of  ”  construct  in  a  Specware  specification  may  sometimes 
result  in  a  translated  Isabelle  Specification  which  is  harder  to  prove.  When  this  happens, 
it  is  always  recommended  to  use  the  if-then-else  construct  instead. 

In  summary,  the  team  discovered  more  “undocumented”  features  in  Specware  and 
Isabelle,  such  as  the  ceiling  limitation  of  the  number  of  elements  supported  in  a  Specware 
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type-product  type.  The  security  model  was  built  and  the  proof  was  discharged  to  Isabelle. 
It  was  found  that  the  proof  could  not  be  completed  automatically  using  the  simp  and  auto 
rules  although  very  trivial  theorems  were  constructed.  Posts  were  made  to  the  Isabelle 
user  group  but  no  response  was  obtained.  It  was  not  easy  to  discern  if  the  problem  arises 
due  to  inherent  inadequacies  in  the  model,  the  translation  performed  by  the  Specware 
Isabelle  Interface  or  just  technicalities  and  know-how  of  guiding  Isabelle  in  its  proof. 
With  limited  time  and  resources,  it  was  decided  that  a  trip  would  be  made  to  Kestrel  to 
seek  first-hand  technical  advice  on  the  model. 

D.  LESSONS  LEARNED  AT  THE  KESTREL  INSTITUTE 

The  visit  to  the  Kestrel  Institute  was  made  with  the  following  objectives: 

•  to  seek  advice  and  guidance  in  proving  using  Isabelle 

•  to  clear  doubts  on  the  interface  between  Specware  and  Isabelle 

•  to  reconfirm  our  modeling  approach  and  to  verily  the  correctness  in  our 
use  of  the  newer  and  not  well  documented  features  of  Specware 

The  initial  version  of  the  BLP  specification  described  in  the  next  section  was  used  for  the 
purpose  of  discussion. 

1.  Specware  Model 

A  walk-through  of  the  specification  was  first  done  with  Dr.  Coglio  Alessandro 
and  Dr.  Stephen  Westfold  from  Kestrel.  Improvements  suggested  are  as  follows: 

•  Use  of  Type-records  in  place  of  Type-products.  Type-records  are 
essentially  similar  to  type-products  except  that  the  components,  called 
“fields,”  are  identified  by  name  instead  of  by  position.  The  ordering  of  the 
“filed-typers”  has  no  significance.  This  makes  the  specification  clearer 
and  more  readable.  An  example  to  illustrate  the  use  of  both  types  is 
shown  in  Figure  53  and  Figure  54. 
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%%  Definition  using  Type-product 

type  Resource  =  ResourceName  *  SecLabel 

%%  Example 

op  label:  Resource  ->  SecLabel 
def  label  (  resrc)  =  resrc.2 

%%  Alternative  way  of  representing  def  function 
%  def  label (name,  lab)  =  lab 


Figure  53  Illustrated  use  of  Type-product 


%%  Definition  using  Type-record 

type  Resource  =  {name:  ResourceName,  label:  SecLabel} 
op  label:  Resource  ->  SecLabel 
def  label  (  resrc)  =  resrc. label 

Figure  54  Illustrated  use  of  Type-record 

•  Use  of  Set  instead  of  List.  The  team  has  always  pondered  the  lack  of  the 
support  for  Set  in  the  Specware  Inbuilt  and  Base  Library.  It  was  only 
understood  during  the  visit  that  the  Set  specification  is  not  released  and 
will  only  be  available  from  Specware  version  4.2.5.  Set  predicates  are 
available  for  use  with  the  use  of  Set,  as  can  be  shown  in  the  BLP  example. 
The  State,  originally  represented  as  a  List  and  manipulated  by  List 
operators,  is  amended  to  be  represented  in  Sets.  The  resultant 
specification  looks  much  more  concise  and  cleaner,  but  it  is  later  found 
that  the  Sets,  being  represented  as  predicates,  lack  the  useful  manipulators 
available  in  Lists. 

•  Use  of  pattern  matching.  Although  not  explicitly  and  extensively 
documented,  pattern  matching  is  a  strength  in  the  Specware  language  and 
the  Kestrel  team  recommended  its  use.  It  is  important  to  note,  though,  that 
its  use  results  in  terse  expressions,  which  though  concise,  may  not  be  as 
readable  to  consumers  of  the  specification. 

2.  Use  of  Monads 

The  team  verified  with  Specware  the  correct  and  apt  use  of  Monad  in  our  BLP 


example.  While  questioning  the  relevancy  of  Monad  use  for  such  a  simple  example,  the 
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Kestrel  team  affirmed  that  our  use  is  appropriate  and  it  correctly  encapsulates  the 
sequenced  operations  and  imperative  code  inside  the  transition  operation.  The  use  of 
Monad,  though,  does  not  make  subsequent  proofing  easier.  It  only  performs  a  certain 
state  of  encapsulation  and  bookkeeping.  It  is  further  verified  that  Exception  Monads  may 
not  be  directly  applicable  and  useful  for  our  simple  model. 

3.  General  Proving  Strategy 

The  Kestrel  team  offered  some  general  advice  on  our  specification  to  facilitate 
proofing.  First,  it  is  recommended  that  the  types  and  operations  must  be  defined  in 
sequence,  as  they  are  used.  Isabelle,  unlike  Specware,  does  not  tolerate  the  usage  of 
types  and  operations  which  have  not  been  defined  at  the  point  where  they  are  used. 
Secondly,  as  a  general  guideline,  it  is  always  good  to  decompose  functions  into  smaller, 
intennediate  functions  as  doing  so  frequently  makes  proving  more  direct  and  easier. 
Proofs  of  the  sub  parts  can  then  be  used  to  compose  proofs  of  composing  types.  Thirdly, 
the  Kestrel  team  cautioned  the  overuse  of  axioms  as  they  may  not  be  totally  consistent 
with  one  another.  This  retards  rather  than  facilitates  proving. 

4.  Proving  Using  Isabelle 

The  Kestrel  team  attempted  the  proving  of  the  BLP  specification  using  Isabelle. 
The  team  observed  that  although  the  theorem  looks  trivial,  the  proof  requires  extensive 
knowledge  and  experience  in  logical  calculus  and  Isabelle.  Isabelle  is  a  powerful 
interactive  theorem  prover  but  has  a  substantial  learning  curve.  The  proof  is  done 
interactively  on  Isabelle  and  the  result  is  copied  back  into  the  original  Specware 
specification.  The  final  specification  and  the  corresponding  proof  will  be  shown  and 
discussed  in  the  next  section. 

Overall,  it  was  a  fruitful  visit  and  a  great  learning  experience.  The  authors  regret 
that  the  visit  was  not  performed  in  an  earlier  stage  of  the  research.  A  lot  more  could  be 
learned  from  the  staff  at  Kestrel  to  supplement  the  inadequacies  in  the  team’s  technical 
knowledge  and  skills  and  the  lack  of  access  to  Specware  examples. 
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E. 


MODELING  BLP  IN  SPECWARE 


1.  Model  Description 

The  concept  of  mandatory  access  controls  was  formalized  by  Bell  and  LaPadula 
in  a  model  commonly  bearing  their  name  [10].  Numerous  variations  of  the  model  have 
since  been  published  but  only  a  very  simplified  version  will  be  considered  in  the  context 
of  this  paper,  for  the  building  of  a  sample  security  model  using  Specware. 

Mandatory  access  control  policy  for  confidentiality1  is  based  on  security  labels 
attached  to  subjects  and  objects.  Subjects  represent  the  entire  entities  of  a  computer 
system,  such  as  processes.  A  label  on  a  user  is  called  security  clearance  and  a  label  on  a 
subject  or  object  is  called  a  security  classification.  The  label  space  forms  a  lattice,  and 
two  labels  are  related  by  a  “dominates”  relation.  Typically  enforced  during  login,  a 
supporting  policy  ensures  that  the  subjects  acting  on  behalf  of  the  users  have  labels  that 
are  dominated  by  the  user’s  clearance.  A  user  with  a  secret  clearance  can  run  the  same 
program  as  a  subject  labeled  secret  or  as  a  subject  labeled  unclassified,  assuming  the 
program  is  labeled  unclassified.  Even  though  both  the  subjects  run  the  same  program  on 
behalf  of  the  same  user,  they  obtain  different  privileges  due  to  their  security  labels.  This 
thesis  addresses  the  security  of  subjects  and  objects,  and  the  modeling  of  the  supporting 
policy  is  left  for  future  work. 

Mandatory  access  BLP  rules  can  be  expressed  as  follows,  with  SecLabel 
representing  the  security  label  of  the  indicated  subject  or  object: 

•  Simple  security  property:  Subject  s  can  read  object  o  only  if  SecLabel(s) 
dominates  SecLabel(o) 

•  *-property:  Subject  s  can  write  object  o  only  if  SecLabel(o)  dominates 
SecLabel(s). 


1  Integrity  policy  is  outside  the  scope  of  this  thesis. 
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2.  Specware  Model 


a.  Required  Library 

The  Specware  General  library  version  4.2.5  is  imported  to  support  on  the 
Set  and  Monad  types  as  shown  in  Figure  55. 

import  /Library/General 

Figure  55  Importing  Specifications  from  General  Library 


b.  Type  Description 

For  this  example,  we  declare  classification  labels  of  Top  Secret,  Secret, 
Confidential  and  Unclassified  to  represent  SecLabel,  which  is  typically  how 
confidentiality  levels  are  defined  in  the  military  world.  In  Figure  56,  a  Resource  is 
declared  to  have  a  name  and  a  label.  Both  Subject  and  Object  are  of  the  type  Resource. 
The  Mode  represents  the  type  of  access. 


%%  Defining  4  types  of  security  labels 

type  SecLabel  =  |  TS_label  |  S_label  |  C_label  |  U_label 

%%  Resource  Related  Types 
type  ResourceName  =  String 

type  Resource  =  {name:  ResourceName,  label:  SecLabel} 
type  Subject  =  Resource 
type  Object  =  Resource 

%%  Access  Mode 

type  Mode  =  |  Read  |  Write 


Figure  56  Security  Label,  Access  Mode  and  Resource  type  Declarations 


c.  Transactions 


Next,  two  transfonn  types  are  defined,  as  shown  in  Figure  57,  which 
represent  the  primary  security  mechanisms  of  the  BLP  model.  The  first,  MakeKnown, 
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adds  a  mode  of  access,  expressed  in  the  form  of  an  AccessTuple,  for  a  subject  to  an 
object  while  the  second,  Tenninate,  removes  a  mode  of  access  for  a  subject  to  an  object. 


%%  Current  Access  Transform  Type  &  Access  Tuple 
type  ATTransaction  =  |  MakeKnown  |  Terminate 
type  AccessTuple  =  Subject  *  Object  *  Mode 


Figure  57  Declaration  of  Access  Tuple  and  Transform  Type 


d.  Input 

The  Input  to  a  transformation  is  declared  in  tenns  of  the  AccessTuple  and 
ATTransaction  as  shown  in  Figure  58. 


%%  Input  Types 

type  Input  =  AccessTuple  *  ATTransaction 
type  InputList  =  List  Input 


Figure  58  Declaration  of  Input  Type 


e.  State 

The  SystemState  represents  the  current  modes  of  access  of  Subjects  to 
Objects.  A  StateMonad  is  defined  for  the  SystemState  along  with  the  corresponding 
return  and  monad  Bind  functions  as  shown  in  Figure  59. 


%%  State  and  StateMonad 
type  State  =  Set  AccessTuple 
type  SystemState  =  State 

type  StateMonad  a  =  SystemState  ->  a  *  SystemState 
%%  Monad  return  and  bind  functions 

op  [a]  return  (x:a) :  StateMonad  a  =  fn  st  ->  (x,  st) 
op  [a,b]  monadBind  (ml:  StateMonad  a,  f:  a  ->  StateMonad  b) : 
StateMonad  b  = 

fn  st  ->  let  (y,stl)  =  ml  st  in 
f  y  stl 


Figure  59  Declaration  of  State  Related  Types,  State  Monad  and  associated  functions 
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SecLabel  is  defined  in  a  LinearOrder.  The  operation  dominates,  in  Figure 
60,  defines  the  Linear  Ordering,  with  Top  Secret  Label  dominating  Secret,  Secret 
dominating  Confidential  and  Confidential  dominating  Unclassified.  The  dominance 
relationship  is  transitive  as  a  result  of  linear  ordering.  For  example,  TSJabel  dominates 
C  label  in  this  case,  due  to  the  fact  that  the  TSJabel  dominating  SJabel  which 
dominates  C  label. 


%%  dominates  function  -  a  security  label  dominates  another 
%%  which  is  of  equal  or  lower  classification 
op  dominates  :  LinearOrder  SecLabel  = 

the  (dominates)  dominates (TS_label,  S_label) 

&&  dominates ( S_label ,  C_label) 

&&  dominates (C  label,  U  label) 


Figure  60  Definition  of  dominates  operation 


f.  Security  Property 

Predicates  on  Sets  are  used  to  assess  if  an  access  or  a  state  is  secure.  An 
access  tuple  is  secure  only  if  the  label  of  the  subject  dominates  that  of  the  object  for  the 
case  when  the  access  mode  is  Read,  and  vice  versa  for  the  case  when  the  access  mode  is 
Write.  Since  this  expresses  essentially  the  set  of  all  possible  secure  tuples,  we  can  express 
a  Secure  State  as  one  which  is  a  subset  of  this  as  illustrated  in  the  securestate?  predicate 
defined  in  Figure  61.  Helper  functions  for  the  Current  Access  are  also  defined  as  shown 
in  Figure  62. 


52 


%%  Checks  if  a  subject  can  access  an  object  using  a 
%%  specified  access  mode  based  on  BLP  rules 
op  access_secure?  :  AccessTuple  ->  Boolean 
def  access_secure?  (subject,  object,  access_mode)  = 
case  access_mode  of 
Read  -> 

dominates  ( sub j ect . label ,  ob j ect . label ) 

Write  -> 

dominates  (obj ect . label ,  sub j ect . label ) 

op  securestate? ( S :  State):  Boolean  = 

S  <=  access_secure? 

op  property?:  (State)  ->  Boolean 
def  property? (s)  =  securestate? ( s ) 


Figure  61  Definition  of  security  predicates  to  check  security  property 


%%  Auxiliary  Functions  for  Current  Access 

to  check  if 

contains 

%%  a  tuple;  Also  for  adding  and  removing 

tuples  from 

Current 

%%  Access  Table 

op  currently  accessible? (at :  AccessTuple): 

:  StateMonad 

Boolean  = 

fn  (S:  State) 

->  (at  in?  S,  S) 

op  addAccess (at : 

AccessTuple) :  StateMonad 

0  = 

fn  (S:  State) 

->  ( () ,  S  <|  at) 

op  removeAccess (at:  AccessTuple):  StateMonad  ()  = 

fn  (S:  State) 

->  ( () ,  S  -  at) 

Figure  62  Definition  of  manipulators  of  Current  Access 


g.  State  Transition/T ransformation 

Figure  63  specifies  the  possible  state  transformations.  As  discussed 
above,  two  transfonn  types  are  defined.  The  first,  MakeKnown,  adds  a  mode  of  access, 
expressed  in  the  fonn  of  an  AccessTuple,  for  a  subject  to  an  object  while  the  second, 
Terminate,  removes  a  mode  of  access  for  a  subject  to  an  object.  evalProgram  takes  in  a 
list  of  input  and  runs  transition  on  them.  The  results  are  returned  in  an  output  list. 
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%%  This  corresponds  to  the  main  function  performing  the  statement 
%%  It  will  read  in  the  next  statement,  perform  it  and  then  call 
next 

op  transition:  Input  ->  StateMonad  Boolean 
def  transition (at,  input_transaction)  = 
case  input_transaction  of 
MakeKnown  ->  { 

curr?  <-  currently_accessed?  at; 
if  -curr?  &&  access_secure?  at 

then  { 

addAccess  at; 
return  true 

}  else 

return  false 

} 

Terminate  ->  { 

curr?  <-  currently_accessed?  at; 
if  curr? 

then  { 

removeAccess  at; 
return  true 

} 

else  return  false 


op  evalProgram:  InputList  ->  StateMonad (List  Boolean) 
def  evalProgram  (inputs)  = 
case  inputs  of 

[]  ->  return  [] 

inp::r  inputs  ->  { 

rl  <-  transition  inp; 

res  <-  evalProgram  r  inputs; 

return ( rl : : res ) 

} 


Figure  63  State  Transition 


h.  Theorems 

Simply  put,  the  theorem  in  Figure  64  just  means  that  the  empty  state  is 
secure.  Empty  state  refers  to  the  state  where  the  current  access  is  empty,  i.e.,  the  state 
where  the  system  has  not  handed  out  any  descriptors  for  access  to  the  resources. 
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%%  theorem  stating  that  an  empty  Current  Access  Matrix 
%%  is  a  secure  state 
theorem  EmptySecure  is 
securestate? (empty) 


Figure  64  Theorem  Empty  is  Secure 


Two  supportive  theorems  (Figure  65)  have  been  added  to  facilitate  the 
eventual  proving  by  Isabelle.  One  states  that  if  the  current  attempted  access  is  secure,  it 
will  be  added  to  the  set  of  access  tuples  which  make  up  the  Current  Access.  It  should  be 
noted  that  this  holds  true  for  the  case  when  the  current  attempted  access  is  already  in  the 
current  access  set.  In  this  special  case,  the  result  of  adding  the  current  access  to  the  set 
will  remain  as  S.  In  the  case  where  the  current  access  is  not  secure,  it  is  not  added  to  the 
Current  Access  set. 


%%  Theorem  stating 

change 

of 

state  after  a  MakeKnown 

transform  type. 

%%  state  will  be  a 

subset 

of 

the  original  state 

theorem  transition 

MakeKnown 

secure  is 

fa (S :  State,  S ' : 

State, 

at 

:  AccessTuple) 

access  secure? 

at  => 

(transition  (at, MakeKnown) 

S) 

.  2  =  S  < |  at 

theorem  transition 

MakeKnown 

not  secure  is 

fa (S :  State,  S ' : 

State, 

at 

:  AccessTuple) 

~ (access  secure?  at) 

=> 

(transition  (at, MakeKnown) 

S)  .2  =  S 

Figure  65  Sub-theorems  for  MakeKnown 


A  similar  theorem  is  formulated  for  the  Terminate  transaction  as  shown  in 
Figure  66.  For  this  case,  tenninate  involves  removal  of  a  tuple  from  the  current  access 
set  if  it  exists.  As  such,  the  resultant  State  should  be  a  subset  of  the  original  State. 


%%  Theorem  stating  change  of  state  after  a  terminate  transform 
%%  type.  New  state  will  be  a  subset  of  the  original  state 
theorem  transition  Terminate  subset  eq  is 
fa(S:  State,  S':  State,  at:  AccessTuple) 

(transition  (at, Terminate)  S) .2  <=  S 


Figure  66  Sub-theorem  for  Terminate 


55 


Next,  the  theorem  transition_state_secure  is  formulated  as  in  Figure  67. 
This  theorem  states  that  given  an  initial  secure  state,  for  any  input,  the  state  transited  to 
will  be  secure  based  on  the  defined  transition  operation. 


%%  Theorem  stating  change  of  state  is  secure 
theorem  transition_state_secure  is 
fa(S:  State,  input: Input) 

securestate? ( S )  =>  securestate? ( (transition  input  S).2) 


Figure  67  Theorem  Transition  State  Secure 


It  should  not  be  difficult  then  to  conclude  that  given  an  initial  empty  state, 
which  is  secure  by  the  theorem  EmptySecure,  the  system  state  will  always  be  secure  as  a 
direct  result  from  transition  state  secure. 


i.  Proving  in  Isabelle 

During  the  session  at  Kestrel,  the  specification  was  translated  to  the 
Isabelle  language  and  Kestrel  provided  examples  of  how  to  use  the  Isabelle  theorem 
prover.  The  proof  steps  are  performed  using  the  Isabelle  graphical  interface,  as  described 
above,  which  can  later  by  copied  into  the  Specware  specification  itself  to  facilitate  re¬ 
proof.  From  this  experience,  we  learned  that  interactive  theorem  proving  is  an  intense 
effort  that  requires  detailed  knowledge  of  both  the  target  specification’s  logic  and  the 
proof  system  —  our  BLP  model  and  the  Isabelle  theorem  prover,  in  this  case.  One 
example,  to  establish  that  the  dominates  operation  is  a  linear  ordering,  was  not  completed 
due  to  time  limitations  of  the  visit,  but  illustrated  how  different  specification  styles,  as 
well  as  proof  strategies,  can  effect  the  elegance  of  the  proof. 


3.  Discussion  and  Lessons  Learned 

Many  of  the  lessons  learned  in  the  building  of  this  submodel  have  been 

documented  and  discussed  in  the  previous  section.  The  most  important  takeaway  was 

that  the  proving  on  Isabelle  platform  is  not  trivial,  and  would  take  more  than  just  simple 

predicate  and  theorem  proofing  knowledge  and  basic  understanding  of  Isabelle  to 

complete  the  proof.  Experience  would  be  another  key  asset,  as  we  saw  how  the  Kestrel 
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team  brilliantly  guided  Isabelle  across  many  of  the  proof  obligations.  The  team  realized 
that  it  would  not  be  possible  to  amass  such  technical  expertise  and  experience  within  the 
time  constraint  of  our  project.  Focus  will  be  placed  instead  on  completing  the  modeling 
ofLPSK. 

F.  MODELING  LPSK  IN  SPECWARE 

1.  Model  Description 

A  separation  kernel  refers  to  hardware  and/or  firmware  and/or  software 
mechanisms  whose  primary  function  is  to  establish,  isolate  and  separate  multiple 
partitions  and  control  information  flow  between  the  subjects  and  exported  resources 
allocated  to  these  partitions.  The  goal  of  the  separation  kernel  is  to  virtualize  and  allocate 
shared  resources  such  that  each  partition  encompasses  a  resource  set  that  appears  to  be 
isolated  from  the  rest. 

The  Principle  of  Least  Privilege  (PoLP)  is  a  foundational  element  in  the  design  of 
high  assurance  systems.  In  the  context  of  computing,  it  requires  that  every  module  (a 
process,  a  user  or  a  program)  must  be  able  to  access  only  such  information  and  resources 
that  are  necessary  for  the  purpose  it  is  built  for.  It  allows  for  the  confinement  of  damage 
when  corruption  of  components  occur  and  as  the  privileges  afforded  each  component  will 
be  minimal,  security  analysis  of  the  TOE  Security  Functions  (TSF)  is  less  complex.  TSF 
is  consequently  more  evaluable  and  accountable. 

The  Center  for  Information  Systems  Security  Studies  and  Research  (CISR) 
created  the  Trusted  Computing  Exemplar  (TCX)  project  to  illustrate  how  trusted 
computing  systems  and  components  can  be  constructed.  The  project  is  developing  a  high 
assurance,  Least  Privilege  Separation  Kernel  (LPSK)  with  a  hosted  trusted  application  as 
a  reference  implementation  for  trusted  computing. 

The  paper  “A  Least  Privilege  Model  for  Static  Separation  Kernels”  [12]  describes 
a  core  Formal  Security  Policy  Model  of  a  separation  kernel  that  enforces  the  Principle  of 
Least  Privilege.  Previous  students  from  NPS  have  specified  elements  of  similar  models 
using  PVS  [1],  Specware  [2]  and  Alloy  specification  languages  [3].  DeCloss’s  model,  in 
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particular,  was  created  using  an  earlier  version  of  Specware  (version  4. 1 .3).  In  his  paper, 
as  part  of  the  scope  for  future  work,  he  suggested  the  use  of  Monads  to  represent  state  in 
Specware  and  enhancement  of  the  model  he  built  in  his  thesis  to  include  requirements  for 
the  TCX  LPSK,  such  as  incorporating  a  notion  of  initialization  of  the  policy  tables  within 
the  model  and  the  modeling  of  a  trusted  partial  ordering  on  the  flows  between  blocks  for 
the  identification  of  “trusted  subjects.” 

The  team  proceeded  to  build  a  model  of  the  TCX  LPSK  using  monadic  state 
representation  and  transition  based  on  the  security  model  which  that  has  been  created  in 
the  preceding  experiments.  Flows  between  subjects  and  objects  are  modeled  as  state 
changes.  The  implementation  is  performed  using  the  latest  release  of  Specware  (version 
4.2.5)  which  was  made  available  to  us  after  the  visit  to  Kestrel  in  November  2008.  This 
version  incorporated  the  new  Set  Base  Library  which  we  found  to  be  useful  in  the 
representation  of  relationships  among  the  various  entities  in  the  model. 

2.  Specware  Model 

a.  Resource  and  Block  Type 

Resources  are  defined  to  be  the  totality  of  all  hardware,  firmware  and 
software  and  data  that  are  executed,  utilized,  created,  protected  or  exported  by  the 
separation  kemel[12]. 

Resources  can  further  be  subtyped  into  exported  resources  and  internal 
resources.  Exported  resources  {Resour ceExt)  refer  to  resources  (including  subjects) 
which  can  be  explicitly  referenced  via  the  separation  kernel  interface.  Conversely, 
internal  resources  ( Resourcelnt )  are  those  which  are  only  available  to  the  kernel  and  to 
which  explicit  reference  is  not  possible.  The  predicates  exported?,  notexported? ,  active? 
and  trusted?  are  declared  to  define  which  resource  is  exported,  internal,  active  and  trusted 
respectively  as  shown  in  Figure  68. 
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op  exported?:  Resource  ->  Boolean 
op  notexported? :  Resource  ->  Boolean 
op  active?:  Resource  ->  Boolean 
op  trusted?:  Resource  ->  Boolean 

type  ResourceExt  =  Resource  |  exported? 
type  Resourcelnt  =  Resource  |  notexported? 


Figure  68  Resource  Types  and  Properties 


An  active  resource  ResourceActive  is  an  external  resource  which  is  active 
and  initiates  operations  on  a  passive  resource.  Examples  of  active  entities  of  a  system 
include  a  program,  a  process  or  an  agent.  In  our  model,  the  type  Subject  is  used  to 
represent  such  an  entity  in  the  separation  kernel. 


type  ResourceActive  =  ResourceExt  |  active? 

type  Subject  =  ResourceActive 

type  TrustedSubj ect  =  Subject  |  trusted? 


Figure  69  Declaration  of  ResoureActive,  Subject  and  TrustedSubject 


A  trusted  subject  ( TrustedSubject )  is  next  defined  in  Figure  69  to  be  a 
subject  that  is  allowed  to  perform  operations  not  normally  allowed  for  ordinary  subjects 
by  policy.  The  concept  of  trusted  subject  being  allowed  to  but  not  required  to  violate 
partial  ordering  is  used  in  the  discussion  on  Partial  Ordering  and  Total  Partial  Ordering 
later. 


The  terms  RSet,  ReSet,  RiSet  and  RsSet  are  declared  next  as  shown  in 
Figure  70  to  represent  the  sets  of  Resource ,  ResourceExt ,  Resourcelnt  and  Subject  in  a 
system  respectively. 


%%  Set  of 

resource 

type 

RSet 

=  Set  Resource 

type 

ReSet 

=  Set  ResourceExt 

%%Set  of  exported  resources 

type 

RiSet 

=  Set  Resourcelnt 

%%Set  of  internal  resources 

type 

RsSet 

=  Set  Subject 

%%Set  of  subjects 

Figure  70  Declaration  of  Resource  Sets 
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The  set  of  ResourceExt  elements  is  partitioned  into  blocks  which  also 
constitute  equivalence  classes.  Every  ResourceExt  element  in  the  specification  is 
assigned  exactly  one  and  only  one  Block  element.  Subjects  and  other  exported  resources 
are  allocated  to  blocks  by  the  separation  kernel.  Conversely,  each  block  defined  must 
have  at  least  a  resource  allocated  to  it  as  an  empty  block  would  not  be  useful.  This  is 
described  by  the  axiom  BlockNotEmpty  in  Figure  71.  BSet  is  declared  to  be  the  set  of  all 
blocks  defined  for  a  particular  system. 


%%  Partitioning  of  resources  into  blocks 
type  Block  =  Set  ResourceExt 

%%  set  of  blocks 
type  BSet  =  Set  Block 

%%  Each  block  must  have  at  least  one  resource  allocated  to 
%%  it  since  an  empty  block  is  useless  and  invalid 
axiom  BlockNotEmpty  is 

fa  (blk:  Block)  nonEmpty? (blk) 


Figure  7 1  Declaration  of  Block  and  BSet 


A  Block  is  defined  to  be  a  set  of  exported  Resources  as  shown  in  Figure 
72.  All  the  resources  inside  a  Block  have  the  same  Blockld  as  described  by  the  axiom 
BlockResourceSameBlockld.  All  Blocks  in  a  system  are  distinct  sets  which  do  not 
overlap.  Any  ResourceExt  in  the  system  must  reside  within  a  Block.  Consequently,  the 
summation  of  all  Resources  inside  all  defined  Blocks  should  equal  that  of  the  entire 
exported  resource  set,  considering  that  no  ResourceExt  is  defined  outside  a  Block.  This  is 
shown  pictorially  in  Figure  72  and  Figure  73,  and  is  specified  by  the  property  propertyRB 
axiom  in  Figure  74. 
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Block  1  Block  2  Block  3  ...  Block  n 


Subjects 

Subjects 

Subjects 

... 

Subjects 

Exported 

Resource 

Exported 

Resource 

Exported 

Resource 

Exported 

Resource 

Exported  Resource  Set 


Figure  72  Blocks  of  Resources 


Subjects 

Exported  Resource 

Internal  Resource 

Resource  Set 


Figure  73  The  Resource  Set 
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%%  All  of  the  resources  of  a  given  Block  type  have  the  same  blkld 
axiom  BlockResourceSameBlockld  is 

fa  (blk:  Block,  resrcl:  ResourceExt,  resrc2 :  ResourceExt) 
resrcl  in?  blk  &&  resrc2  in?  blk 
=>  resrcl. blkld  =  resrc2.blkid 

%%  returns  true  if  all  blocks  in  a  given  BSet  are  distinct  and  do 
%%  not  overlap 

op  distinctSets (bset :  BSet)  :  Boolean  = 
fa(bl:  Block,  b2 :  Block) 
bl  in?  bset 
&& 

b2  in?  bset 
&& 

(bl  /\  b2  =  empty 
bl  =  b2 ) 

%%  System  element  axiom 

%%  Union  of  the  resources  of  all  blocks  equals  the  resource  set 
%%  No  other  resource  exists  other  than  those  is  sys . resources 
%%  Blocks  of  sys . resources  are  distinct 

axiom  propertyRB  is 
fa  (sys:  System) 

( \ \ / /  (sys. blocks)  =  sys . sysstate . resrcset  /\  (fn  (i)  -> 
exported? ( i ) ) ) 

&& 

(full?  sys . sysstate . resrcset) 

&& 

distinctSets (sys. blocks) 


Figure  74  Property  of  Block 

In  our  model,  a  Resource  object  is  defined  as  in  Figure  75  by  a  unique  Resource 
ID,  a  block  identifier  (Blockld)  that  identifies  the  block  the  resource  belongs  to  and  the 
memory,  essentially  a  set  of  bits,  assigned  to  the  resource.  The  memory  attribute  will  be 
used  in  the  formulation  of  the  flow  property  pertaining  to  read  and  write  operations. 
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type  Resourceld  =  String 

%%  Identifier  for  block 
type  Blockld 

%%  Resource 

type  Resource  =  {rscid:  Resourceld,  blkid:  Blockld, 
rscmem:  ResourceMemory } 

Figure  75  Declaration  of  a  Resource 

A  Block  is  defined  to  be  just  strictly  a  set  of  Resources  without  adding  an 
explicit  BlockID  as  an  attribute.  This  is  to  conform  to  the  mathematical  notion  of  a  block 
in  a  partition,  facilitates  comparison  and  allows  set  operations  between  a  Block  and  the 
Resource  set.  As  a  result  of  this  definition,  a  number  of  helper  operations  have  to  be 
defined  to  retrieve  a  Block  based  on  its  Blockld  and  also  to  retrieve  the  Blockld  from  a 
given  Block.  The  operations  getBlock  and  getBlockld  used  in  perfonning  these  respective 
functionalities  are  implemented  as  below  in  Figure  76.  Given  the  set  of  exported 
resources  ReSet  and  the  partition  of  those  resources  B,  the  function  RB  retrieves  the  block 
id  from  a  specified  ResourceExt  object.  Note  that  these  operations  could  have  just  been 
left  as  abstract  functions  but  the  team  furnished  their  implementations  to  make  the  model 
as  complete  as  possible.  In  the  specification,  the  team  was,  however,  hampered  by  the 
non-availability  of  documentation  for  the  newly  released  Set  Base  Library  and  the  lack  of 
helper  functions  for  this  Library  to  iterate  and  extract  Set  elements  for  manipulation.  The 
resultant  implementation  consequently  looks  cumbersome  as  only  the  onlyMember 
operation  was  available  at  the  team’s  disposal  to  retrieve  a  member  from  a  set  which  is  a 
Singleton.  Although  axioms  could  be  and  have  been  defined  to  ensure  that  such  sets  are 
Singleton,  we  are  still  left  with  the  ugly  “if-then-else”construct  in  the  functions  as 
onlyMember  could  also  be  invoked  on  a  set  which  is  a  Singleton. 
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Block  Manpulation  Operations 

Needed  for  linking  resource  to  the  block  it  belongs  to  &  vice  versa 

•k-k'k-k'k-k-k-k'k-k'k-k-k-k-k-k'k-k'k-k-k-k-k-k'k-k'k-k'k-k'k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k'k-k-k'k-k-k-k-k-k-k-k'k-k'k-k'k-k'k-k'k^ 

op  blockMatchBlockld  :  Block  *  Blockld  ->  Boolean 
def  blockMatchBlockld  (blk,  blkld)  = 

fa  (  resrc:  ResourceExt)  resrc  in?  blk  =>  resrc.blkid  =  blkld 

%%  Retrieving  the  blocks  of  given  block-set  that  match  a  given 
%%  blockid 

op  filterBlock  (blockset  :  BSet,  blkld  :  Blockld)  :  BSet  = 
blockset  /\  (fn  i  ->  blockMatchBlockld ( i ,  blkld)) 

%%  Retrieve  the  block  from  a  given  block-set  that  match  a  given 
%%  blockid 

op  getBlock  (blockset  :  BSet,  blkld  :  Blockld)  :  RSet  = 
let  bset  =  filterBlock (blockset,  blkld)  in 
if  single?  bset 

then 

theMember  bset 

else 

empty 

%%  Return  the  ID  of  a  given  block 
op  getBlockld:  Block  ->  Blockld 
def  getBlockld (blk)  = 

let  idset  =  map  (fn  i  ->  i.blkid)  blk  in 
theMember  idset 

%%  Return  the  block  id  of  a  given  resource 
op  RB  :  ResourceExt  ->  Blockld 
def  RB(res)  =  res.blkid 


Figure  76  Definition  of  Block  and  related  operations 


b.  Flow 

Next,  the  notion  of  a  flow  is  introduced  in  Figure  77  after  declaring  the 

various  types  of  resources  and  blocks.  A  flow  is  declared  as  a  tuple  of  Subject, 

ResourceExt  and  FlowModeSet.  Only  two  modes  of  flow  ( ModeOfFlow ),  Read  and 

Write,  will  be  considered  in  our  simplified  model,  ignoring  a  possible  execute  mode 

presented  in  the  paper  [12].  The  FlowModeSet  attribute  specifies  the  modes  of  flow  under 

consideration  from  the  source  which  is  a  Subject  to  the  destination  which  is  a 

ResourceExt.  Since  it  is  represented  as  a  set,  it  is  not  required  to  define  a  NULL  type  and 
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a  RW (read  write)  type  as  what  DeCloss  has  done  in  his  model.  An  empty  FlowModeSet 
will  indicate  no  flow  and  a  set  containing  both  Read  and  Write  modes  of  flow  will  be 
equivalent  to  the  RW  representation  in  DeCloss’s  model.  Our  description  does  not 
exclude  the  possibility  that  the  destination  is  another  Subject.  A  Transform  is  a  collection 
of  Flow  tuples.  Each  operation,  as  used  in  the  paper,  is  associated  with  a  Transform 
object  which  represents  the  resultant  flows  of  an  invocation.  The  function  MM  represents 
all  the  flows  between  pairs  of  resources  which  will  be  actualized  by  the  system 
operations.  It  is  declared  in  our  model  as  a  set  of  Transforms  as  it  is  the  cumulative 
collection  of  all  actualized  flows  from  system  operations. 


%%  Flow  related 

type  ModeOfFlow  =  |  Read  |  Write 
type  FlowModeSet  =  Set  ModeOfFlow 

%%  Flow  effect  &  Set  of  all  possible  flow  effects 

type  Flow  =  {subj:  Subject,  obj :  ResourceExt,  fset:  FlowModeSet} 

%%  Defines  all  effects  associated  with  an 
type  Transform  =  Set  Flow 
type  MM  =  Set  Transform 

operation/ transform 

Figure  77  Dcfiniton  of  Flow,  FlowEffect,  Transform  and  MM 


A  flow  policy  defining  the  least  privilege  flow  control  between  Subject 
and  ResourceExt  and  the  block-to-block  flow  control  between  Blocks  will  be  defined  next. 
The  two  flow  policies  are  orthogonal,  i.e.,  a  flow  allowed  in  one  may  not  necessarily  be 
allowed  in  the  other  policy.  The  Policy  object  is  defined  to  be  made  up  of  two  matrices 
as  shown  in  Figure  78. 


%%  Policy  is  preset  and  passed  in  during  initialisation 
type  Policy  =  { srm: SRMatrix,  bbm:  BBMatrix} 


Figure  78  Definition  of  Policy 


The  least  privilege  flow  control  is  defined  by  a  subject-resource  matrix 
(SRMatrix)  which  contains  a  collection  of  flow  tuples  depicting  allowed  flows  between  a 
Subject  and  a  ResourceExt  defining  the  least  privilege  flow  policy.  The  function  SR  as 
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shown  in  Figure  79  extracts  out  from  the  SRMatrix  the  tuple  corresponding  to  the  Subject 
and  ResourceExt  specified.  Each  SRMatrix  should  contain  at  most  one  flow  tuple 
corresponding  to  each  Subject  and  ResourceExt  pair  as  ensured  by  the  axiom 
SRSingleEntrySubjObjPair.  If  the  tuple  is  not  found  in  the  SRMatrix,  it  is  assumed  that 
no  flow  is  allowed  between  that  Subject  and  ResourceExt  pair.  This  is  equivalent  to  an 
empty  fset  for  the  Subject  and  Resource. 


^kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

Subject  to  Resource  Policy  and  Flows 

Check  is  based  on  the  policy  matrix  specified 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk J 

%%  Subject  to  Resource  flow  record 
type  SRMatrix  =  Set  Flow 

%%  returns  the  modes  of  flow  allowed  between  a  given  subject  and 
%%  resource  in  a  given  SRmatrix 

op  SR(pol:  SRMatrix,  subj :  Subject,  extobj :  ResourceExt)  : 
FlowModeSet  = 

let  bset  =  pol  /\  (fn  i  ->  (i.subj  =  subj)  && 

(i.obj  =  extobj))  in 
case  single?  bset  of 

true  ->  (theMember  bset) .fset 
false  ->  empty 

axiom  SRSingleEntrySubjObjPair  is 

fa  (pol  :  SRMatrix,  subj :  Subject,  extobj :  ResourceExt) 
let  bset  =  pol  /\  (fn  i  ->  (i.subj  =  subj)  && 

(i.obj  =  extobj))  in 
single?  bset  | |  empty?  bset 


Figure  79  Definition  of  SRMatrix 


Block-to-block  flow  control  policy  is  defined  by  the  BBMatrix  in  Figure 
80.  BBMatrix  contains  a  set  of  BBRecord  tuples  which  specify  the  set  of  flow  modes 
allowed  between  a  source  block  and  a  destination  block.  The  operation  BB  locates  the 
BBRecord  inside  the  BBMatrix  for  a  specified  pair  of  source  and  destination  and  returns 
the  set  of  allowed  flows  from  the  source  to  the  destination.  For  any  defined  Block  a,  a 
flow  from  any  block  to  itself  is  always  allowed.  This  is  defined  in  the  axiom 
BB  FLOWS  BLOCK  INTERNAL  ALLOWED. 
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%%  Block  to  Block  flow  record 

%%  Represents  flow  of  information  between  blocks 
%%  BBMatrix  contains  tuples  depicting  a  Set  of  FlowModes 
%%  between  2  blocks.  If  a  BBRecord  linking  2  blocks  is  not 
%%  found,  no  allowable  flow  is  allowed  source  is  bl,  dest  is  b2 
type  BBRecord  =  {bl:  Block,  b2 :  Block,  fset:  FlowModeSet} 
type  BBMatrix  =  Set  BBRecord 

Block  to  block  Policy  and  Flows 

Check  is  based  on  the  policy  matrix  specified 

-k-k-k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k'k-k'k-k'k-k-k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k-k-k-k^ 

%%  Retrieve  allowed  flows  modes  from  block  a  to  block  b  from 
%%  given  policy  matrix 

op  BB(bb:  BBMatrix,  a:  Blockld,  b:  Blockld)  :  FlowModeSet  = 
let  bset  =  bb  /\ 

(fn  i  ->  (getBlockld ( i . bl ) =a  &&  getBlockld ( i . b2 ) =b) )  in 
case  single?  bset  of 

true  ->  (theMember  bset) .fset 
false  ->  empty 

%%  No  other  blocks  exist  other  than  those  in  sys. blocks 
%%  All  blocks  can  both  read  and  write  to  themselves 
axiom  BB_FLOWS_BLOCK_INTERNAL_ALLOWED  is 
fa  (sys:  System,  a:  Block) 
let  bid  =  getBlockld (a)  in 
full?  sys. blocks  && 

Write  in?  BB ( sys . pol . bbm,  bid,  bid)  && 

Read  in?  BB ( sys . pol . bbm,  bid,  bid) 


Figure  80  Definition  of  BB 

On  completion  of  the  discussion  on  flow  and  flow  policy,  we  are  now 
ready  to  describe  what  a  system  is.  In  the  LPSK  paper,  the  following  elements  are  used 
to  define  a  System  following  a  least  privilege  separation  model: 

•  a  set  of  resources  RSet 

•  a  set  of  operations  O  (this  translates  to  Transform  in  our  model) 

•  a  set  of  modes  of  flow  FlowModeSet 

•  a  partitioning  of  resources  into  a  set  of  blocks  BSet 

•  an  operation-to-effects  function  MM 

•  a  block-to-block  flow  function  BB 

•  a  subject- to-resource  flow  function  SR 
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A  system  can  thus  be  represented  as  =  (RSet,  Transform,  FlowModeSet,  BSet,  MM,  BB, 
SR).  In  our  model,  it  is  recognized  that  the  FlowModeSet  has  already  been  defined  in  the 
model  under  type  specification.  A  complete  description  of  a  System  will  need  to  include 
both  its  static  and  dynamic  elements.  Under  static  elements,  BSet  has  to  be  specified  to 
define  how  the  resources  are  assigned  to  blocks  and  MM  to  define  the  actualized 
Transform  in  the  system.  BB  and  SR  have  to  be  furnished  at  system  initialization  in  the 
form  of  a  Policy  object  containing  the  BBMatrix  and  a  SRMatrix.  The  two  matrices  are 
initialized  during  system  startup  and  remain  static  thereafter.  For  dynamic  element,  the 
system  state,  State,  is  defined.  This  contains  the  flows  that  are  currently  enabled  for  the 
subjects  and  also  the  set  of  system  resources  (RSet).  System  resources  are  included  under 
State  as  the  memory  attribute  ( ResourceMemory )  of  Resource  may  change  with  state 
transition.  Figure  81  shows  the  definition  of  System  and  State  types. 


type  System  =  {blocks:  BSet,  systemflows:  MM,  pol:  Policy, 
sysstate:  State} 

%%  State  contains  the  flows  that  are  currently  enabled  for 
sub j  ects , 

%%  and  also  the  set  of  system  resources 

type  State  =  {atset:  Set  Flow,  resrcset:  RSet} 


Figure  8 1  Definition  of  System  and  State 


Figure  82  shows  the  relationship  of  the  primary  model  elements  of  the  system.  Flow  is  a 
central  model  component  and  is  used  in  State  in  the  definition  of  the  accesses  that  are 
enabled,  in  Transform  to  represent  data  flow  that  have  been  actualized  and  in  the  Policy 
object  to  define  allowed  data  flows. 
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Figure  82  System  Components  and  their  Relationships 


c.  System  State 


The  set  of  resources  defined  under  State  can  be  divided  into  a  set  of 
exported  resources  and  a  set  of  internal  resources.  The  sets,  RiSet  and  ReSet  are  distinct 
and  do  not  overlap  as  depicted  by  the  set  relation  in  Figure  83. 


axiom  propertySystemSetResource  is 
fa(sys:  System) 

let  intres  =  sys . sysstate . resrcset  /\ 

(fn  (i)  ->  notexported?  (i) )  in 
let  exres  =  sys . sysstate . resrcset  /\ 

(fn  (i)  ->  exported?  (i) )  in 
(intres  \/  exres  =  sys . sysstate . resrcset)  && 
(intres  /\  exres  =  empty) 


Figure  83  Property  of  Resource  Set 
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It  was  defined  earlier  in  Figure  75  that  every  resource  has  resource 
memory  ( ResourceMemory ).  The  ResourceMemory  is  defined  to  be  a  set  of  bits. 
Potentially,  the  set  could  also  be  empty  if  the  resource  is  not  loaded  by  the  kernel  or  no 
memory  has  been  assigned  to  the  resource.  For  the  model,  the  case  where  there  is  no 
overlap  of  memory  between  resources,  as  defined  by  property  ResourceMemory  Distinct, 
is  assumed. 


%%  Memory  related 

type  Bit 

type  ResourceMemory  =  Set  Bit 
type  Memory  =  Set  Bit 

axiom  propertyResourceMemoryDistinct  is 
fa  (resrcl:  Resource,  resrc2 :  Resource) 

( resrcl . rscmem  /\  resrc2 . rscmem)  =  empty  | |  resrcl  =  resrc2 


Figure  84  Definition  of  Memory 


To  analyze  how  state  changes  will  transition  inside  our  model,  the  system 
state  needs  to  be  defined.  For  the  purpose  of  our  model,  a  system  state  is  defined  to 
consist  of  a  set  of  access  tuples  and  a  set  of  resources  ( RSet )  as  in  Figure  85.  As  already 
mentioned,  State  represents  the  components  of  the  system  that  can  change.  An  access 
tuple  represents  a  request  to  the  kernel  for  access  to  a  system  resource.  It  is  expressed  in 
the  form  of  a  Flow  object.  The  kernel  arbitrates  every  access  attempt  and  determines  if 
an  access  is  allowed  based  on  the  transaction  type  (. ATTTransaction )  defined  in  Figure  85 
and  the  policy  of  the  system.  Four  transaction  types  have  been  defined  for  the  model. 
Each  transaction  potentially  causes  some  change  in  the  system  state.  ReadExternal  and 
WriteExternal  in  particular  may  result  in  a  flow  in  the  system.  The  read_op  and  write_op 
are  abstract  operations  but  they  invoke  flows  which  result  in  changes  in  the  subject  and 
accessed  object’s  memories  respectively.  Changes  in  the  memory  of  subject  and  object 
memories  are  captured  in  the  resrcset  component  of  the  State. 
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type  ATTransaction  = 

MakeKnown 

Terminate 

ReadResourceExt 

I  WriteResourceExt 

Figure  85  Different  types  defined  in  ATTTransaction 


d.  State  Monads 

The  State  Monad  is  declared  as  in  the  previous  model  for  BLP.  Additional 
State  Monads  are  defined  in  Figure  86  to  access  and  change  the  state  variables,  namely 
atset  and  resrcset.  The  function  currently ^accessible?  checks  to  see  if  a  particular  access 
has  already  been  granted  by  the  system  through  a  prior  MakeKnown  transaction  type  call. 
add_access  adds  and  enables  an  access  atset  while  remove_access  removes  all  tuples  and 
accessses  associated  with  the  subject  and  object  specified  which  have  been  previously 
enabled  from  atset.  The  operations  read_op  and  write_op  are  invoked  via 
ReadResourceExt  and  WriteResourceExt  transaction  type  calls  respectively  only  when 
the  specified  input  Flow  is  enabled. 


^kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

State  Monad  Definition 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk J 

type  StateMonad  a  =  State  ->  a  *  State 

op  [a]  return  (x:a) :  StateMonad  a  =  fn  st  ->  (x,  st) 
op  [a,b]  monadBind  (ml:  StateMonad  a,  f:  a  ->  StateMonad  b) : 
StateMonad  b  = 

fn  st  ->  let  (y,stl)  =  ml  st  in 
f  y  stl 

(kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

System  state  functions. 

State  Monads  for  accessing  and  changing  the  state  variables 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk'j 

op  get_access_by_at  (at:  Flow) :  StateMonad  (Set  Flow)  = 

fn  (S:  State)  ->  (S. atset  /\  (fn  i  ->  ((i.subj  =  at.subj)  && 

(i.obj  =  at.obj))),  S) 

%%  Access  Functions  to  retrieve  and  set  values  inside  states 
op  currently_accessible? (at :  Flow):  StateMonad  Boolean  = 

{ 

curr  <-  get_access_by_at  at; 

return  ((single?  curr)  &&  (at.fset  <=  (theMember  (curr) ). f set) ) 
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op  add_access (at :  Flow) :  StateMonad  ()  = 

{ 

curr  <-  get_access_by_at  (at)  ; 
if  (single?  curr) 

then 

{ 

remove_access  (at) ; 

curr_at  <-  get_current_access ; 

put_current_access  (curr_at  <| 

{ 

subj  =  at. sub j, 
obj  =  at.obj, 

fset  =  (theMember  ( curr) ).f set  \/  at. f set 

} 

)  ; 

return  () 

} 

else 

return  () 


op  remove_access (at:  Flow) :  StateMonad  ()  = 
fn  (S:  State)  -> 

((),  {atset  =  S.atset  --  (fn  i  ->  (i.subj  =  at. subj)  && 

(i.obj  =  at.obj)),  resrcset  =  S.resrcset}) 

op  get_current_access :  StateMonad  (Set  Flow)  = 
fn  (S:  State)  ->  (S.atset,  S) 

op  put_current_access ( inatset :  Set  Flow):  StateMonad  ()  = 

fn  (S:  State)  ->  ((),  {atset  =  inatset,  resrcset  =  S.resrcset}) 

op  read_op:  Subject  *  ResourceExt  ->  StateMonad  () 
op  write_op:  Subject  *  ResourceExt  ->  StateMonad  () 

op  get_resource :  StateMonad  (RSet)  = 
fn  (S:  State)  ->  (S.resrcset,  S) 

op  get_resource_memory :  Resource  ->  StateMonad  (Set  Bit) 

Figure  86  State  Monads  for  state  access  and  modification 


e.  Security  Predicates 

To  evaluate  the  security  of  the  state  and  its  transitions,  security  predicates 
as  shown  in  Figure  87  are  defined  to  check  the  security  of  accesses  and  the  security 
properties  of  the  system,  access _al lowed?  checks  to  see  if  a  subject  can  access  an 
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external  resource  with  the  mode  specified  based  on  system  policy,  access jsecure? 
encapsulates  the  access _allowed? ,  providing  a  check  on  whether  an  access  is  allowed 
based  on  an  input  access  tuple. 


op  access  allowed?:  SRMatrix  *  BBMatrix  *  Subject  *  ResourceExt  * 
FlowModeSet  ->  Boolean 

def  access_allowed?  (srm,  bbm,  subject,  object,  am)  = 
am  <=  (SR(srm,  subject,  object))  && 
am  <=  (BB(bbm,  sub j ect . blkid,  ob j ect . blkid) ) 

op  access  secure?  :  SRMatrix  *  BBMatrix  *  Flow  ->  Boolean 

def  access_secure?  (srm,  bbm,  {subj  =  subject,  obj  =  object, 
fset  =  am})  = 

access_allowed? ( srm,  bbm,  subject,  object,  am) 


Figure  87  Security  predicates 


The  transition  operation,  which  transits  the  state  based  on  an  Input  object 
and  the  system  policy,  is  next  defined.  The  Input  object  is  made  of  two  attributes,  an 
AccessTuple  detailing  the  subject,  object  and  flow  mode  requested,  and  an 
ATTransaction  flag  indicating  the  type  of  transaction  sought  by  the  caller.  More  detail  of 
the  different  ATTransaction  types  and  their  effects  on  the  state  are  given  in  Table  3.  The 
corresponding  Specware  definition  is  given  in  Figure  88. 


Transaction 

Type 

Description 

Make  Known 

Making  a  request  for  access  as  described  by  the  specified 

AccessTuple.  An  entry  is  added  to  the  AccessTuple  table  if  the 

access  is  allowed  by  policy  and  the  access  tuple  is  not  currently 

present  in  the  set  of  AccessTuples  in  system  state.  Accesses  have 

to  be  made  known  before  ReadExternal  and  WriteExternal 

operations  may  be  made. 

Terminate 

Making  a  request  to  terminate  all  accesses  as  specified  by  the 

AccessTuple.  The  mod  field  is  ignored  and  all  accesses  related  to 

the  subj  and  obj  specified  are  removed 
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Read  External 

Making  a  request  for  the  subj  to  read  the  obj  specified.  The  mod 

field  is  ignored  and  we  define  that  some  state  change  has  occurred 

if  a  change  in  the  subj  memory  results  from  the  read  op, 

Effectively,  a  flow  has  occurred  from  the  obj  to  the  subj. 

Write  External 

Making  a  request  for  the  subj  to  read  the  obj  specified.  The  mod 

field  is  ignored  and  we  define  that  some  state  change  has  occurred 

if  a  change  in  the  obj  memory  results  from  the  write  op. 

Effectively,  a  flow  has  occurred  from  the  subj  to  the  obj. 

Table  3.  Transaction  types  supported  in  model 


type  Input  =  {at:  Flow,  attran:  ATTransaction } 

op  transition:  Input  *  System  ->  StateMonad  Boolean 
def  transition ( inp,  sys)  = 
let  policy  =  sys.pol  in 
let  at  =  inp. at  in 
let  inputtran  =  inp. attran  in 

case  inputtran  of 

MakeKnown  -> 

{ 

curr?  <-  currently_accessible?  at; 

if  -curr?  &&  access_secure? (policy . srm,  policy. bbm,  at) 

then  { 

add_access  at; 
return  true 

} 

else  return  false 

} 

Terminate  -> 

{ 

curr?  <-  currently_accessible?  at; 
if  curr? 

then  { 

remove_access  at; 
return  true 

} 

else  return  false 

} 

ReadResourceExt  -> 

{ 

_ curr?  <-  currently  accessible?  at; _ 
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if  curr? 

then  { 

b4resourceMem  <-  get  resource  memory (at . subj ) ; 
read_op (at . subj ,  at.obj); 

afterresourceMem  <-  get_resource_memory (at . subj ) ; 
return  ( 

ex  (memsect:  Set  Bit) 

~ (memsect  <=  b4resourceMem) 

&& 

(memsect  <=  at . ob j . rscmem) 

&& 

(memsect  <=  afterresourceMem) 

) 

} 

else  return  false 

} 

WriteResourceExt  -> 

{ 

curr?  <-  currently_accessible?  at; 
if  curr? 

then  { 

b4objMem  <-  get_resource_memory (at . obj ) ; 
write_op (at . subj ,  at.obj); 

afterobjMem  <-  get_resource_memory (at . obj ) ; 
return  ( 

ex  (memsect:  Set  Bit) 

~ (memsect  <=  b4objMem) 

&& 

(memsect  <=  at . sub j . rscmem) 

&& 

(memsect  <=  afterobjMem) 

) 

} 

else  return  false 


Figure  88  Definition  of  transition  operation 


f.  Security  Theorems 

In  Figure  89,  the  top  level  encapsulating  operation  which  initializes  the 
system  and  furnishes  an  input  list  is  defined.  This  may  be  useful  in  formulating  general 
theorems  involving  an  arbitrary  number  of  inputs,  e.g.,  an  InputList  of  arbitrary  length 
and  results  in  the  state  resulting  from  the  InputList  transition,  and  a  list  of  Boolean  results 
corresponding  to  the  success  of  failure  of  these  transitions. 
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type  InputList  =  List  Input 

op  evalProgram:  InputList  *  System  ->  StateMonad (List  Boolean) 
def  evalProgram  (inputs,  sys)  = 
case  inputs  of 

I  []  ->  return  [] 

inp::r  inputs  -> 

{ 

rl  <-  transition  (inp,  sys); 

res  <-  evalProgram  (r  inputs,  sys); 

return (rl : : res) 


Figure  89  Encapsulating  function 


A  few  theorems  of  our  model,  some  corresponding  to  those  defined 
previously  for  the  BLP  example,  can  now  be  formulated. 

The  first  operation  in  Figure  90,  secure_write_transition,  states  that  an 
invocation  of  write  op  will  result  in  a  change  in  the  object  memory.  The  actualization  of 
the  flow  from  the  Subject  to  the  object  ( ResourceExt )  implies  that  the  flow  is  currently 
enabled.  Correspondingly,  the  secure  read  transition  states  that  an  invocation  of 
read_op  will  result  in  a  change  in  the  Subject  memory.  In  this  case,  the  occurrence  of  the 
flow  from  the  object  to  the  Subject  implies  that  the  flow  is  enabled;  i.e.,  the  flow  is 
present  inside  the  access  tuple  set  at  the  point  of  invocation  of  read_op.  These  two 
operations  are  essential  as  they  define  that  a  flow  actualized  by  a  State  change  must  be 
one  that  is  enabled  for  a  system  to  be  secure. 

The  securestate?  predicate  checks  to  see  if  the  state  of  the  system  is  secure 
based  on  the  contents  of  the  access  tuple  set.  A  state  is  defined  as  secure  if  all  the 
elements  of  the  access  tuple  set  satisfy  access _secure? 

The  theorem  EmptySecure  describes  that  a  system  state  whereby  the 
access  tuple  set  is  empty  is  secure.  The  StateMonad  currently _accessible?  predicate  will 
always  return  a  false  for  all  invocations  and  no  flow  will  result  based  on  our  defined 
model. 
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The  next  theorem,  SecureSystem,  states  three  properties  for  a  System  to  be 
secure.  Firstly,  if  the  current  state  is  secure,  a  transition  will  result  in  the  next  state  also 
being  secure.  Also,  an  actualization  of  a  flow  in  the  system  due  to  a  read  or  write 
operation  for  a  particular  system  state  implies  that  the  flow  is  enabled  for  that  system 
state.  From  the  two  theorems,  we  would  also  be  able  to  deduce  that  starting  from  an 
empty  secure  state,  all  subsequent  states  should  be  secure  based  on  the  properties  defined 
in  SecureSystem. 


op  secure_write_transition (SI :  State,  at:  Flow):  Boolean  = 
if  (Write  in?  at. f set)  then 

let  S'  =  (  write_op  (at.subj,  at.obj)  SI). 2  in 
( (get_resource_memory  (at.obj)  SI) . 1  ~= 
(get_resource_memory  (at.obj)  S').l)  => 
(currently__accessible?  at  Sl).l 

else 

false 

op  secure_read_transition (SI :  State,  at:  Flow):  Boolean  = 
if  (Read  in?  at. f set)  then 

let  S'  =  (read_op  (at.subj,  at.obj)  SI) .2  in 
( (get_resource_memory  (at.subj)  SI) . 1  ~= 
(get_resource_memory  (at.subj)  S').l)  => 
(currently_accessible?  at  SI) . 1 

else 

false 

op  securestate? ( S :  State,  policy:  Policy):  Boolean  = 
fa(at:  Flow)  at  in?  S.atset 

=>  access_secure? (policy . srm,  policy. bbm,  at) 

theorem  EmptySecure  is 
fa(sys:  System) 

sys . sysstate . atset  =  empty  && 

securestate? (sys . sysstate,  sys . pol) 

theorem  SecureSystem  is 

fa(S:  State,  input: Input,  sys:  System) 
securestate? ( S ,  sys. pol) 

=>  securestate? ( (transition  (input,  sys)  S).2,  sys. pol) 
&& 

secure  write  transition ( S ,  input. at) 

&& 

secure_read_transition (S,  input . at) 


Figure  90  Security  Theorems  for  secure  state 
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Partial  Ordering  and  Trusted  Partial  Ordering 


g- 


Figure  91  shows  our  attempt  to  specify  the  Partial  Ordering  of  the  inter  block 
flows  defined  by  BB.  Partial  Ordering  is  a  relation  defined  on  a  set,  having  the  properties  that 
each  element  is  reflective,  the  relation  is  transitive,  and  if  two  elements  are  in  relation  to  each 
other,  the  two  elements  are  equal  (antisymmetric).  The  Partial  Ordering  of  BB  ensures  that 
information  is  not  allowed  to  flow  circularly  among  the  blocks  in  the  relationship,  i.e.,  if 
information  leaves  a  block  there  is  no  transitive  flow  that  will  lead  the  information  back  to  the 


block,  direct  Jlowjo  is  defined  as  a  helper  function  to  restrict  flow  consideration  to  only  those 
direct  flows  between  the  two  blocks  under  consideration. 
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Partial  Ordering  of  BB 

Semantics  to  describe  flows  between  blocks  to  be  defined  in  such  a 
way  that  information  is  not  allowed  to  flow  circularly,  i.e.  if 
information  leaves  a  block,  there  is  no  transitive  flow  that  will 
lead  back  to  itself.  Important  to  note  that  any  2  blocks  are  not 
required  to  be  related  by  a  flow. 
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op  direct  flow  to?(bb:  BBMatrix,  a:  Blockld,  b:  Blockld)  :  Boolean  = 
Write  in?  BB(bb,  a,  b)  %%  a  ->  b,  caused  by  a 

Read  in?  BB(bb,  b,  a)  %%  a  ->  b,  caused  by  b 

op  PO(blkset:  BSet,  bb:  BBMatrix) :  Boolean  = 
fa  (i:  Block,  j:  Block,  k:  Block) 

(i  in?  blkset)  &&  (j  in?  blkset)  &&  (k  in?  blkset)  => 

%%  Refective  Property 

direct_flow_to? (bb,  getBlockld (i) ,  getBlockld (i) ) 

&& 

%%  Antisymmetric 

( 

(direct_flow_to? (bb,  getBlockld ( i ) ,  getBlockld ( j ) ) 

&& 

direct_flow_to? (bb,  getBlockld ( j ) ,  getBlockld ( i ) ) 

)  =>  (i  =  j) 

)  && 

%%  Transitive 

( 

(direct_flow_to? (bb,  getBlockld ( i ) ,  getBlockld ( j ) ) 

&& 

direct_flow_to? (bb,  getBlockld ( j ) ,  getBlockld ( k) ) 

)  =>  direct_flow_to? (bb,  getBlockld ( i ) ,  getBlockld ( k) ) 
_ ) _ 

Figure  91  Definition  of  Partial  Ordering 
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The  Partial  Ordering  is  employed  in  the  subsequent  specification  of 
Trusted  Paired  Ordering  for  the  system.  The  notion  of  a  trusted  subject,  defined  at  the 
beginning  of  this  specification  example,  is  used  here.  A  trusted  subject  has  been  defined 
as  one  that  is  trusted  not  to  downgrade  information  other  what  is  intended  for 
downgrading.  Given  a  partial  ordering  for  B ,  called  Bbase,  a  trusted  partial  ordering  for 
the  system  is  defined  as  in  Figure  93  B contra  is  a  subset  of  BB  containing  flows  in 
contradiction  to  those  identified  in  Bbase.  The  operation  derivebbflowset  in  Figure  92 
derives  the  set  of  flows  from  the  BBRecords  inside  the  BBMatrix.  This  is  needed  for 
comparison  with  the  systemflows  set. 


%%  BBMatrix  contains  a  set  of  BBRecord  record{block,  block,  flowset} 
%%  We  would  like  to  extract  out  the  allowed  flows  from  this,  bearing 
%%  in  mind  that  a  flow  is  a  tuple  consisting  of  a 
%%  {subject,  object,  fmode} 

op  derivebbflowset (bbm:  BBMatrix) :  Set  Flow  = 
let  setsetflow  =  map  (bb2flowset)  bbm  in 
\ \ / /  setsetflow 

op  bb2f lowset (bb :  BBRecord) :  Set  Flow  = 

let  blsubject  =  bb.bl  /\  (fn  i  ->  active? (i) )  in 

let  b2object  =  bb.b2  in 

let  bbduple  =  blsubject  *  b2object  in 

map  (fn  (a,b)  ->  {subj  =  a,  obj  =  b,  fset  =  bb.fset})  bbduple 


Figure  92  Definition  of  op  to  extract  flows  from  BBMatrix 


'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

Trusted  Partial  Ordering  of  BB 

Bbase:  Trusted  partial  ordering  for  system 

Trusted  Subject  is  a  Subject  that  has  undergone  rigorous  analysis  & 
is  trusted  not  to  downgrade  information  other  than  the  information 
it  is  intended  to  downgrade. 

He  is  allowed  but  not  required  to  violate  the  partial  ordering. 
Flows  will  exist  in  the  System  that  will  violate  the  partial 
ordering,  (bcontra) 

'k'k'k'k'k'k'k-k'k'k'k-k'k'k'k'k'k'k'k-k'k'k'k-k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

theorem  TPO  is 

fa(sys:  System,  bbase:  BBMatrix) 

ex  (blkset:  BSet,  bcontra:  Set  BBRecord) 
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bcontra 

BBRecord 


and 


RB (rs) )  , 


%%  System  Transform  flows  will  be  totality  of  bbase  & 

%%  Note  that  transform  flows  are  a  set  of  flows  while 

%%  depicts  a  flow  from  a  block  to  another  block 
%%  derivebbf lowset  extracts  all  possible  subject  to  resource 
%%  flow 

\\//sys . systemf lows  =  derivebbf lowset (bbase  \/  bcontra) 

&& 

PO(blkset,  bbase)  && 

( 

fa  (  rs :  Resource,  r:  Resource,  f:  Set  ModeOfFlow) 

%%  Flow  must  be  allowed  in  bcontra  but  not  bbase 
f  <=  BB (bcontra,  RB(rs),  RB(r))  && 

%%  Flow  must  be  allowed  in  SR 
f  <=  SR ( ( sys . pol ) . srm,  rs,  r)  && 

%%  Upon  adding  the  equivalence  of  the  flow  from  rs  to  r, 
%%  partial  ordering  no  longer  holds  for  the  block  set 

%%  new  bbase 
~  ( 

PO  ( 

blkset,  (bbase  <|  {bl  =  getBlock ( sys . blocks , 
b2  =  getBlock ( sys . blocks ,  RB(r)),  fset  =  f}) 

) 

) 


%%  rs  must  be  a  trusted  subject 

=>  (exported? (rs)  &&  active? (rs)  &&  trusted? ( rs ) ) 


Figure  93  Definition  of  Trusted  Partial  Ordering 


3.  Discussion  and  Lessons  Learned 

Building  of  the  LPSK  model  specification  started  only  after  our  visit  to  Kestrel  in 

late  October  2008.  The  Kestrel  team  recommended  the  use  of  the  Specware  Set  Base 

Library  instead  of  the  List  Base  Library  which  the  team  had,  along  with  DeCloss  [2]  in  a 

previous  project,  thus  far  depended  upon.  The  Set  Base  Library  was  introduced  only  in 

the  latest  version  of  Specware  (version  4.2.5),  which  was  officially  released  in  November 

2008.  As  this  library  is  new,  we  analyzed  the  Set  specification  itself  to  leam  about  the 

inbuilt  operations  and  their  uses.  Unlike  the  List  Base  Library  which  comes  with  a  set  of 
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utility  functions  for  transversal  and  manipulation,  the  Set  Library  does  not  provide  many 
support  functions.  For  example,  the  Member  function  is  the  only  retrieval  operation 
available  and  it  works  on  a  Singleton  set,  i.e.,  a  set  containing  only  a  single  element.  A 
conscious  effort  had  been  made  in  the  model  to  use  sets  as  much  as  possible,  as  it  is  most 
natural  and  appropriate  for  the  LPSK  model  where  sets  of  resources  and  associated 
properties  are  considered.  The  team  recognizes  that  some  of  the  expressions  in  our 
model  appear  overly  cumbersome  and  suspect  that  there  may  be  better  and  more  concise 
ways  to  represent  them.  The  refinement  of  the  specification  has  been  left  as  a  potential 
scope  of  later  work,  when  proper  documentation  and  practical  examples  of  the  Specware 
Set  Base  Library  are  made  available. 

Readers  should  note  that  the  team  has  chosen  to  go  down  the  track  of  just 
modeling  flows  related  to  exported  resources.  Flow  effects  have  been  specified  only  in 
terms  of  the  flows  between  subjects  ( RsSet )  and  exported  resources  (ReSet).  For 
example,  flow  has  been  declared  as  a  tuple  of  subject,  exported  resource  and  a  set  of  flow 
mode.  For  the  model  to  be  more  complete,  e.g.,  with  respect  to  noninterfernace, 
additional  axioms  and  properties  may  have  to  be  defined  to  ensure  separation  policy 
regarding  internal  resources.  Due  to  time  constraints,  this  is  not  covered  in  this  thesis. 
An  alternative  approach  would  be  to  conduct  a  comprehensive  covert  channel  analysis  of 
the  system  and  specifications  to  provide  the  evidence  for  separation  of  internal  resources. 

In  the  modeling,  the  team  has  not  attempted  to  build  an  abstract  model  and  a  final 
target  model  as  has  been  perfonned  by  DeCloss  [2].  Morphism  is  supported  and  is  a 
strong  feature  in  Specware  and  it  may  be  useful  if  the  team  first  develops  a  canonical 
abstract  security  model  which  is  refined  only  in  its  subsequent  target  model.  This  will 
allow  the  reuse  of  the  specification  for  other  models  and  also  allow  modellers  to  focus  on 
only  the  areas  they  want  to  focus  on  at  the  point  of  modeling. 

For  our  current  model,  additional  suggested  follow  up  specification  work  includes 
specification  of  semantics  of  read_op  and  write_op  which  currently  are  abstract 
operations  which  result  in  changes  in  the  subject  and  object  memory  respectively.  It  is 
also  important  to  note  that  the  use  of  “if-then-else”  (Figure  94)  constructs  in  our  model, 

particularly  in  the  transition  operation  may  make  subsequent  refinement  attempts  more 
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difficult.  It  would  be  convenient  if  it  can  be  replaced  with  a  chained  predicate  construct 
(Figure  95)  prevalent  in  functional  programming.  The  team  briefly  investigated  how  to 
replace  the  construct  as  c  is  a  Monadic  State  Transition  function  that  returns  a 
StateMonad  Boolean  rather  than  just  a  Boolean,  and  the  completion  of  this  effort  was  left 
for  future  work. 


if 

(a  &&  b)  then  c 

Figure  94 

“if-then-else”  construct 

3L  Sc  Sc  fc>  Sc  Sc  C 

Figure  95 

Chained  predicate  construct 

For  the  model  to  be  useful,  additional  work  is  needed  to  verify  it,  discharge  its 
proof  obligations  and  attempt  proving  them  using  a  tool  like  Isabelle  in  order  to  prove  the 
security  properties  related  to  the  model.  Subsequently,  execution  codes  may  also  be 
generated  directly  from  the  model.  It  is  important  to  note,  though,  that  the  use  of  Set  may 
potentially  hamper  the  translation  to  execution  code  as  sets  may  be  infinite.  When  such 
refinement  to  executable  code  is  desired,  ‘FiniteSet’  should  be  used  in  the  specification  in 
place  of ‘Set.’ 

Specware  does  not  support  the  declaration  of  model-level  variables  and 
parameters,  unlike  other  specification  languages  like  Prototype  Verification  System 
(PVS).  As  a  result,  for  every  defined  axiom  or  theorem,  operation  level  parameters  have 
to  be  redeclared  and  used,  making  the  specifications  more  cumbersome  and  less  flexible. 
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V.  RESULTS  AND  ANALYSIS 


It  is  demonstrated  in  this  thesis  that  the  translation  from  Specware  to  Isabelle  can 
be  seamlessly  achieved  using  the  Specware  to  Isabelle  Translator.  The  team  has  also 
completed  the  building  of  a  LPSK  model  using  Monads  and  the  Set  base  library  released 
in  Specware  version  4.2.5.  Results  and  recommendations  pertaining  to  the  different 
areas  of  exploration  are  summarised  below. 

A.  SPECWARE 

MetaSlang  in  Specware  is  a  rich  language  for  specifying  the  security  model,  but 
the  available  documentation  is  not  sufficient  for  a  beginner  to  achieve  functional 
programming;  in  particular,  more  examples  are  needed.  To  help  beginners  to  smoothen 
the  learning  curve  for  Specware  we  recommend  that  the  Specware  Language  manual  [26] 
include  more  exhaustive  examples  of  how  each  of  the  Mestaslang  constructs  can  be  used, 
and  that  the  tutorial  documentation  include  more  sample  specifications  in  Specware. 
Also,  documentation  built-in  and  examples  for  the  new  Set  base  library  should  be 
included. 

The  current  version  of  Specware  for  Linux  does  the  support  the  use  of  x-symbols, 
as  x-symbols  have  some  conflicts  with  the  version  of  XEmacs  used.  X-symbols  are  useful 
when  writing  the  specification  as  they  greatly  enhance  the  readability  of  the  specification. 

Email  support  from  the  Kestrel  Institute  on  Specware  has  been  responsive  but  is 
currently  provided  by  a  single  person  at  Kestrel.  A  discussion  group  or  forum  would  be 
extremely  useful  for  one  who  is  just  learning  the  language.  It  would  promote  a  more 
proactive  and  interactive  learning  environment  and  provide  a  learning  ground  for 
beginners  to  learn  from  each  other  and  to  share  their  learning  experiences. 

B.  ISABELLE 

While  SNARK  is  an  automatic  theorem  prover,  Isabelle  is  an  interactive  theorem 
prover  with  automatic  proving  capability,  where  the  user  needs  to  have  substantial 
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knowledge  and  experience  in  logical  calculus  to  complete  a  proof.  Although  Isabelle 
provides  a  very  extensive  list  of  documentation,  most  of  the  documentation  assumes  a 
strong  background  and  experience  in  proof  logic.  An  introductory  guide  with  illustrated 
examples  on  how  proving  strategies  and  how  proving  may  be  guided  interactively  in 
Isabelle  would  be  most  useful  for  beginners.  Auto  proving  in  Isabelle  succeeds  only  for 
simple  and  trivial  theorems,  as  experienced  by  the  team.  Proving  becomes  more  manual 
when  the  theorems  become  more  complicated.  Subtheorems  could  be  added  as 
intennediaries  for  guiding  the  proofs. 

Isabelle  has  a  large  user  group  with  two  mailing  lists,  a  user  mailing  list  and  a 
developer  mailing  list.  The  mailing  lists  will  be  useful  for  beginners  to  post  questions, 
and  learn  from  developers  and  fellow  users.  It  is  noted,  though,  that  answers  are 
provided  only  out  of  goodwill  and  it  is  not  guaranteed  that  responses  will  be  received 
upon  posting  of  questions  to  the  forum.  Still,  it  will  be  extremely  useful  for  beginners  to 
learn  from  past  queries  posted  by  others. 

C.  SPECWARE  TO  ISABELLE  TRANSLATION 

Although  Specware  to  Isabelle  translation  is  considered  as  an  initial  experimental 
release  [20],  it  provides  an  almost  seamless  translation  from  Specware  specification  to 
Isabelle  specification  using  the  Specware  to  Isabelle  interface.  It  is  recognized  that  it  is 
still  work  in  progress  and  rare  instances  exist  where  the  convertor  may  turn  out  Isabelle 
syntax  which  is  not  accepted  by  Isabelle.  The  team  has  reported  a  few  such  encounters  to 
Kestrel  and  many,  such  as  the  one  involing  the  use  of  “case-of  ’  construct,  have  been 
resolved  in  Specware  version  4.2.5.  A  number  of  these  may  not  be  implementation  bugs 
but  rather  design  and  implementation  decisions  by  Kestrel  but  were  undocumented. 

When  the  problems  are  encountered  with  proving  in  Isabelle,  first  the  cause  of  the 
problem  must  be  detennined,  e.g.,  whether  it  is  caused  by  an  inadequacy  in  the 
translation  tool  or  that  the  proof  demands  more  input  from  the  user.  This  is  a  time- 
consuming  process  for  users  with  limited  knowledge  about  the  intrinsics  in  the  translation 
and  the  syntax  of  the  Isabelle  language. 
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D. 


SETTING  UP  OF  SPECWARE/ISABELLE  DEVELOPMENT 
ENVIRONMENT 


Specware  and  Isabelle,  together  with  the  Specware  Isabelle  Interface,  currently 
are  not  supported  on  Windows.  The  development  environment  for  the  project  was  set  up 
on  a  Fedora  8  platform  running  as  a  VMWare  virtual  machine  on  a  Windows  Vista 
machine.  Glitches  were  encountered  during  the  setup  and  valuable  time  was  spent 
getting  the  software  to  work.  To  make  the  process  as  painless  as  possible  for  new  users, 
we  have  furnished  detailed  documentation  on  the  setup  process  in  this  report.  The  setup 
was  done  using  Specware  4.2.2  and  Isabelle  2008  version.  The  Graphical  User  Interface 
also  appears  slightly  unstable  and  incessant  refreshing  resulting  in  blinking  of  windows 
was  occassionally  encountered.  Specware  and  Isabelle  can  alternatively  be  run  on  Mac 
OS  environment  but  this  is  not  explored  in  the  project.  It  is  also  possible  to  run  Isabelle 
on  Windows  using  Cygwin. 

E.  SETS 

The  newly  released  Set  library  provides  a  convenient  and  more  natural  way  for 
modeling  set  relations  and  collections  as  compared  to  the  use  of  List.  In  the  LPSK 
model,  the  team  used  the  Set  library  extensively  to  model  the  key  model  components  and 
their  relationships.  Resource,  Block,  policy  matrices  ( BBMatrix  and  SRMatrix )  and  the 
access  matrix  (AccessTuple)  are  implemented  as  sets  in  our  model.  Set  predicates  are 
employed  in  many  of  the  axioms  and  theorems  formulated.  Appropriateness  and 
correctness  of  use  of  the  Set  Library  inside  our  model  could  be  verified  when 
accompanying  documentation  and  examples  become  available. 

F.  MONADS 

Monads  allow  the  embedment  of  an  imperative  programming  element  into 
functional  programming  code  but  it  does  not  seem  to  simplify  the  proving  process  on 
Isabelle.  The  concept  of  Monads  is  not  easily  grasped  and  not  much  supporting 
documentation  exists  in  the  Specware  user  manual.  The  team  was  able  to  learn  to  use 
Monads  from  the  visit  to  Kestrel  and  the  many  available  Haskell  resources  on  the  web 
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and  from  building  simple  examples,  emulating  the  Haskell  ones  widely  available  on  the 
web.  Monads  are  successfully  used  in  the  LPSK  to  model  flows  between  subjects  and 
objects. 


G.  LPSK 

The  team  successfully  modeled  the  notions  of  state  changes  and  data  flows  in  the 
LPSK  model.  Compared  to  Decloss’s  model,  the  model  is  more  concrete  and  this  is 
possible  with  the  use  of  Set  notation  and  Monads.  The  notion  of  flow  is  central  to  the 
model  and  is  used  to  represent  requests  made,  the  access  table  and  also  the  actualized 
data  flows  between  resources. 

The  system  is  modeled  such  that  all  accesses  to  systems  are  arbitrated  requests 
made  in  the  form  of  transactions.  The  system  maintains  an  access  table  and  grants 
accesses  based  on  the  defined  system  policy.  Transactions  are  divided  into  two  groups, 
those  that  change  the  access  table  and  those  that  change  the  memory  of  the  resources. 

With  the  above  defined,  the  team  formulated  security  theorems  regarding 
transactions  and  actualized  flows.  Readers  should  note  that  operations  are  not  restricted 
to  the  two  representative  ones,  ReadResourceExt  and  WriteResoruceExt,  currently 
handled  by  our  model.  The  notion  of  a  secure  state  is  coined  based  on  the  existing 
system  state  at  a  point  in  time.  A  Transaction  would  result  in  state  changes,  and  hence  it 
is  necessary  to  ensure  that  a  transaction  always  brings  a  secure  state  to  another  secure 
state.  This  is  ensured  if  the  flow  associated  with  the  Transaction  is  allowed  and  enabled 
by  the  system.  Conversely,  the  team  also  successfully  depicted  in  the  model  that  if  a 
flow  occurs  for  a  system  state,  it  must  be  because  the  flow  has  been  enabled  in  the  access 
table  in  that  particular  state. 

Consequently,  the  concept  of  a  SecureSystem  is  straightforward.  It  is  defined  as  a 
summation  of  these  properties  of  Transaction  and  Flow. 
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VI.  CONCLUSION 


A.  CONCLUSION 

In  the  course  of  this  thesis  work,  the  team  attempted  to  come  to  terms  with  Fonnal 
Methods  (FM)  tools  starting  from  a  minimal  mathematical  background  and  knowledge 
about  these  tools.  Given  the  state  of  FM  tools  today,  the  learning  curve  is  complex  and 
intellectually  steep  but  momentum  picks  up  after  negotiating  the  first  few  slopes.  The 
team  was  lucky  to  be  exposed  to  both  the  model  checking  (e.g.,  refutation  as  in  Alloy 
Analyzer)  and  theorem  proving  (as  in  Specware  and  theorem  prover  like  PVS  and 
Isabelle)  to  appreciate  both  types  of  FM.  The  team’s  work,  however,  was  very  much 
limited  to  security  modeling  and  code  verification  using  Specware  and  Isabelle.  There  is 
a  great  deal  more  to  be  learned  in  this  area. 

The  main  challenges  encountered  by  the  team  include  coping  with  the 
mathematics  and  proving  logic  and  paradigm  shift  between  imperative  programming  and 
functional  programming,  the  limited  documentation  and  examples  on  Specware  and  the 
overwhelming  load  of  documentation  and  details  in  Isabelle  where  we  struggled  to  locate 
the  logical  starting  point.  However,  as  this  was  a  team  effort,  and  even  though  we  were 
far  from  being  twice  as  productive,  we  learned  and  tackled  the  frequent  problems 
encountered  together. 

We  found  that  with  a  translator  to  Isabelle,  Specware  has  become  more  complete 
as  a  verification  tool.  The  XEmacs  environment  that  integrates  both  Specware  and 
Isabelle  is  simple,  allowing  the  developer  to  become  familiar  and  comfortable  with  both 
Specware  and  Isabelle  in  a  relatively  short  period  of  time,  which  is  an  improvement  over 
the  earlier  version  of  Specware  that  DeCloss  used  in  his  thesis  [2], 

MetaSlang,  the  specification  language  in  Specware,  is  a  simple  and  expressive 
language.  MetaSlang  can  represent  state  transition  either  as  a  history  list  that  can  be 
processed  recursively  or  as  a  state  Monad.  The  representation  of  Monads  in  MetaSlang  is 
very  similar  to  Haskell,  a  popular  functional  programming  language,  and  therefore  should 
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be  easily  understandable  by  someone  that  is  familiar  with  functional  programming. 
However,  for  a  beginner  it  requires  a  substantial  amount  of  effort  to  understand  and  use 
them.  We  have  documented  our  understanding  of  Monads  in  this  thesis  in  hopes  of 
smoothing  the  learning  curve  for  Monads. 

It  was  found  that  the  translation  between  Specware  and  Isabelle  is  almost 
seamless  and  that  there  is  much  potential  in  the  use  of  Isabelle/HOL  to  discharge  proof 
obligations  that  arise  in  developing  Specware  specifications.  The  actual  proving  using 
Isabelle  requires  substantial  knowledge  and  experience  in  logical  calculus,  which  put 
closed  results  outside  the  scope  of  this  thesis. 

In  conclusion,  through  our  work  in  this  thesis  we  found  that  Specware,  together 
with  Isabelle,  has  great  potential  for  specifying  and  verifying  a  security  model.  They  will 
be  great  tools  for  experienced  user  in  the  theorem  proving  field.  We  hope  that  the 
illustrated  use  of  Sets  and  Monads  in  our  LPSK  example  will  also  be  useful  to  future 
users  of  Specware. 

B.  FUTURE  WORKS 

1.  Proving  of  the  Model  Using  Isabelle 

Isabelle  is  an  interactive  theorem  prover  with  lots  of  capabilities  that  had  yet  to  be 
explored  in  this  thesis.  Further  studies  may  be  perfonned  to  understand  the  various 
approaches  in  theorem  proving  using  Isabelle  and  the  pros  and  cons  of  each  approach. 
With  the  understanding  of  each  theorem  proving  approach,  a  complete  proof  for  the 
LPSK  model  could  be  explored. 

2.  Segregation  of  the  Model  into  an  Abstract  Canonical  Model  and  a 
Refined  Model 

No  conscious  effort  has  been  put  in  when  specifying  the  LPSK  model  to  first 
create  an  abstract  model  which  is  subsequently  refined.  Work  could  be  done  to  segregate 
a  reusable  canonical  abstract  model  from  the  current  specification.  Refinements  to  the 


88 


model  can  also  be  supported  with  Specware’s  morphism  features  to  specify  a  concrete 
level  representative  of  the  LPSK  API  and  functional  behaviour. 

3.  Code  Generation  from  a  Verified  Model  using  Specware 

Code  generation  is  one  of  the  capabilities  of  Specware.  It  is  known  that  infinite 
sets  could  not  be  converted  to  code  using  the  code  generation  functionality  of  Specware. 
Research  can  be  conducted  to  understand  the  process  of  code  generation  and  generate  an 
executable  code  from  a  verified  model. 

4.  Running  Specware/Isabelle  on  Alternative  Platforms 

Running  Specware  and  Isabelle  on  alternative  platfonns  like  MacOS  and 
Windows  may  be  further  explored  as  it  will  eliminate  our  current  dependancy  on  Fedora. 
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APPENDIX  A.  GCD  EXAMPLE 


A.  HASKELL  EXAMPLE2  [19] 


A  short  example  shows  how  the  StateTrans  Monad  let  you  code  in  a  fairly 
imperative  style.  We  will  implement  a  variation  on  Euclid’s  algorithm  for  finding  the 
greatest  common  divisor  (GCD)  of  two  positive  integers  as  shown  in  Figure  96. 


while  x  ! =  y 
do 

if  x  <  y 

then 

y  :=  y-x 

else 

x  :=  x-y 
return  x 


Figure  96  Euclid’s  Algorithm  for  calculating  GCD 
First  we  must  define  a  type  to  represent  the  state  as  in  Figure  97. 


type  ImpState  =  (Int,  Int) 


Figure  97  Declaration  of  State 


Next  we  define  some  simple  state  transformers  (Figure  98)  to  access  and  change 
the  state.  We  use  the  type  ()  and  its  sole  value,  (),  when  a  state  transfonner  does  not 
return  a  useful  value. 


2 


This  example  is  reproduced  from  an  internet  tutorial  [19],  with  some  changes  in  wording. 
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Figure  99  Haskell  Specification 


And  finally,  a  function  to  construct  an  initial  state,  run  the  program  and  discard 
the  final  state  as  shown  in  Figure  100. 

greatestCommonDivisor  x  y  =  snd (  applyST  gcdST  (x,y)  ) 

Figure  100  Encapsulating  GCD  function 

This  small  example  only  hints  at  the  utility  of  Monads.  It  would  be  much  shorter 
to  write  the  algorithm  in  a  conventional  functional  style.  For  one  thing,  Monads  provide 
access  to  global  state  and  the  savings  from  not  having  to  explicitly  pass  the  state  around 
become  larger  as  the  program  itself  becomes  larger. 

B.  CORRESPONDING  EXAMPLE  IN  SPECWARE 

We  create  a  Specware  model  corresponding  to  the  Haskell  one  to  calculate  GCD. 
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%%  Contains  the  current  values  of  the  2  inputs  to 

%%  calculate  gcd  on 

type  GCDState  =  Nat  *  Nat 


Figure  101  Declaration  of  GCDState 


A  StateMonad  is  defined  and  the  template  specifications  supplied  by  the  Kestrel 
Institute  are  used  as  shown  in  Figure  102  below. 


%%  StateMonad  defined  based  on  the  GCDState  with  corresponding 

%%  monadic  return  and  bind  functions 

type  StateMonad  a  =  GCDState  ->  a  *  GCDState 

op  [a]  return  (x:a) :  StateMonad  a  =  fn  st  ->  (x,  st) 

op  [a,b]  monadBind  (ml:  StateMonad  a,  f:  a->StateMonad  b) : 

StateMonad  b  = 

fn  st  ->  let  (y,stl)  =  ml  st  in 
f  y  stl 


Figure  102  Declaration  of  Monads  and  Monadic  Function 


State  Monadic  functions  are  defined  to  retrieve  both  X  and  Y,  and  also  to  update 
X  and  Y  as  shown  in  Figure  103. 


%%  Retrieving  X  and  Y  value 
op  getX  :  StateMonad  Nat 
def  getX  =  (fn  (x,y)  ->  (x. 

(x,  y)  )  ) 

op  getY  :  StateMonad  Nat 
def  getY  =  (fn  (x,y)  ->  (y. 

(x,  y)  )  ) 

%%  Updating  X  and  Y  values 

op  putX  :  Nat  ->  StateMonad 

0 

def  putX (input)  =  (fn  (x,y) 

->  (  0  , 

(input, y) ) ) 

op  putY  :  Nat  ->  StateMonad 

0 

def  putY (input)  =  (fn  (x,y) 

->  (  0  , 

(x, input) ) ) 

Figure  103  X  and  Y  Manipulators 


Finally,  the  gcdST  core  function,  which  does  recursive  calculation  of  the  greatest 
common  divisor,  is  defined  in  Figure  104.  Note  that  the  sequenced  calculations  are 
encapsulated  inside  the  gcdST  operation. 
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%%  State  Transition  function  gcdST  which  calculate  and  update  the 
%%  values  of  X  and  Y 

op  gcdST:  StateMonad  Nat 
def  gcdST  =  { 
x  <-  getX; 
y  <-  getY; 
if  (x  =  y) 
then 

%%  Passing  back  the  final  result 
return  x 
else 

%%  Recursive  call  if  x  and  y  not  equal 
if  (x  <  y) 
then  { 

putY  (y-x) ; 
gcdST 
}  else  { 

putX  (x-y) ; 
gcdST 

} 


Figure  104  State  Transition  Function  gcdST 


Finally,  the  encapsulating  operation  for  top  level  invocation  is  defined  as  shown 
in  Figure  105.  This  allows  us  to  furnish  an  initial  state  and  applies  it  recursively  to  obtain 
the  result.  The  greatestCommonDivisor  further  encapsulates  the  applyST  by  furnishing 
the  initial  state  in  terms  of  its  individual  components. 


%%  Encapsulating  operation  invoked  with  initial  state 
op  applyST  :  StateMonad  Nat  ->  GCDState  ->  Nat  *  GCDState 
def  applyST  (fnsm)  (initstate)  =  fnsm (initstate) 

%%  Top  level  Encapsulating  operation  with  2  input  numbers  to 
%%  calculate  gcd  on 

op  greatestCommonDivisor:  Nat  *  Nat  ->  Nat 

def  greatestCommonDivisor  (x,y)  =  (applyST  gcdST  (x,y)).l 


Figure  105  Encapsulating  Function  and  Initialization 
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APPENDIX  B.  BLP  ^-PROPERTY  MODEL 


A.  TYPEDEFSPEC.SW 

%%  This  specification  contains  all  the  type  declaration  required 
%%  by  the  BLP  *-property  specification 

TypeDef  =  spec 

%%  Initial  type  declaration 

type  Name  =  String 

type  Value  =  Integer 

type  Index  =  Nat 

type  ProgCounter  =  Nat 

type  Label  =  |  High  |  Low 

%%  Variable  declaration 

type  Variable  =  Name  *  Value  *  Label 

type  Variables  =  List  Variable 

%%  Input  declaration 

type  Input  =  (List  Value)  *  Index 

%%  Statement  declaration 

%%  assignl  -  variable  name  =  variable  name,  eg  a  =  b 

%%  assign2  -  variable  name  =  value,  eg  a  =  5 

type  TypeOfStmt  =  |  ReadLow  |  ReadHigh  |  WriteLow  |  WriteHigh 
Assignl  |  Assign2  |  Ifthenl  |  Stop 

%%  Left-hand  part 
type  LHP  =  Name 

%%  Right-hand  part 

type  RHP  =  |  VarName  String  |  VarValue  Integer 

%%  used  to  indicate  the  index  for  next  statement  to  execute 
%%  normally  first  ProgCounter  is  used. 

%%  but  when  conditional  statement  like  if-then-else  is  used 
%%  the  first  ProgCounter  is  for  positive  evaluation  in  if  and 
%%  the  second  ProgCounter  is  for  the  negative  evaluation  in  else 
type  NextProgCounter  =  ProgCounter  *  ProgCounter 

%%  Statement  declaration 

type  Stmt  =  Name  *  TypeOfStmt  *  LHP  *  RHP  *  NextProgCounter 
%%  Program  declaration 

type  Program  =  (List  Stmt)  *  ProgCounter 

%%  Memory  State  declaration  -  Variables,  Low  Input,  High  Input 
type  MemoryState  =  Variables  *  Input  *  Input 
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%%  System  state  declaration  -  Variable,  Low  Input,  High  Input, 
Program 

type  SystemState  =  Variables  *  Input  *  Input  *  Program 
endspec 


B. 


MEMORY  SPE  C .  S  W 


%%  This  specification  contains  all  the  functions  required 
%%  manipulation  of  Memory  state  (variable,  high  input  and 
MyMemory  =  spec 

%%  Memory  State  contains  of  3  components 
%%  (1)  Variables:  List  of  Variable 
%%  Variable:  Tuple  with  2  fields 
%%  Name [String]  :  Name  of  Field 

%%  Value [ Integer ]  :  Value  of  Field 

of  Low  Values. 

Value  of  Low  Input 
Points  to  next  low  input  to  read 
of  High  Values. 


for 

low 


input) 


(2)  InputLow:  List 
Value [Integer] 
Index [ Integer] 

(3)  InputHigh:  List 


Value [Integer] 
Index [ Integer] 


Value  of  High  Input 
Points  to  next  high 


input  to  read 


import  TypeDef Spec#TypeDef 

type  MemoryStateValueTuple  =  MemoryState  *  Value 

%%  Axion  #1:  Input  List  Index  <=  length  input  list 
axiom  len  input  list  is 

fa  (mem_state:  MemoryState) 

let  inputLow  =  mem  state. 2  in 
let  inputHigh  =  mem  state. 3  in 

inputLow. 2  <  length ( inputLow . 1 )  &&  inputHigh. 2  < 

length ( inputHigh . 1 ) 

proof  Isa  [simp]  end-proof 

%%  Read  from  the  low  input  list  based  on  the  current  index 
op  read  inputLow  :  MemoryState  ->  Integer 
def  read  inputLow (mem  state)  = 

nth (mem  state. 2.1,  mem  state. 2. 2) 
proof  Isa  [simp] 

using  len  input  list 
apply (auto) 
end-proof 

%%  Read  from  the  high  input  list  based  on  the  current  index 
op  read  inputHigh  :  MemoryState  ->  Integer 
def  read  inputHigh (mem  state)  = 

nth (mem  state. 3.1,  mem  state. 3. 2) 
proof  Isa  [simp] 

using  len  input  list 
apply (auto) 
end-proof 
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%%  Read  from  the  low  input  list  based  on  the  current  index 
%%  Increment  Index 
%%  Returns  the  value  read 

op  read  low  :  MemoryState  ->  MemoryStateValueTuple 
def  read_low  (mem_state)  = 

let  read  value  =  read  inputLow (mem  state)  in 

let  updated  input  stream  =  (mem  state. 2.1,  succ (mem  state. 2. 2)) 
in 

let  updated  memory  =  (mem  state. 1,  updated  input  stream, 
mem_state.3)  in 

(updated_memory,  read_value) 
proof  Isa  [simp]  end-proof 

%%  Read  from  the  high  input  list  based  on  the  current  index 
%%  Increment  Index 
%%  Returns  the  value  read 

op  read  high  :  MemoryState  ->  MemoryStateValueTuple 
def  read  high  (mem  state)  = 

let  read  value  =  read  inputHigh (mem  state)  in 

let  updated_input_stream  =  (mem_state . 3 . 1 ,  succ (mem_state . 3 . 2 ) ) 
in 

let  updated  memory  =  (mem  state. 1,  mem  state. 2, 
updated  input  stream)  in 

(updated_memory,  read_value) 
proof  Isa  [simp]  end-proof 


%%  Find  the  variable  from  the  variable  list 
%%  based  on  variable  name  and  return  the  variable 
op  find  variable  :  Name  *  MemoryState  ->  Option  Variable 
def  find  variable (var  name,  mem  state)  = 

find  (fn  i  ->  compare (var  name,  i.l)  =  Equal)  (mem  state. 1) 
proof  Isa  [simp]  end-proof 

%%  Update  the  varibale  with  the  new  value 

op  update  variable  :  Name  *  Value  *  Label  *  MemoryState  -> 

MemoryState 

def  update  variable (var  name,  var_value,  var  Label,  mem  state)  = 

let  new  var  =  insert ( (var  name,  var  value,  var^Label) ,  filter  (fn  i 
->  compare (var  name,  i.l)  ~=  Equal)  (mem  state. 1))  in 
(new  var,  mem  state. 2,  mem  state. 3) 
proof  Isa  [simp]  end-proof 

endspec 

C.  STATEMENTSPEC.SW 

%%  This  Specification  contains  all  the  functions 
%%  that  are  required  by  the  BLP  *-property  model 
%%  to  execute  the  different  type  of  statements 
Statement  =  spec 

import  MemorySpec#MyMemory 

%  GT  -  Greater  than 
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%  LT  -  Less  than 

%  GE  -  Greater  or  Equal 

%  LE  -  Less  than  or  Equal 

%  EQ  -  Equal 

%  NEQ  -  Not  Equal 

type  Cond  =  |  GT  |  LT  |  GE  |  LE  |  EQ  NEQ 

%%  function  to  read  from  low  input  and  assign  to  variable  specified 
by  LHP 

op  read  low  func  :  LHP  *  MemoryState  ->  MemoryState 
def  read  low  func  (var  name,  mem  state)  = 

let  read  value  =  (read  low (mem  state)) .2  in 

update  variable (var  name,  read  value.  Low,  mem  state) 
proof  Isa  [simp]  end-proof 

%%  function  to  read  from  high  input  and  assign  to  variable  specified 
by  LHP 

op  read  high  func  :  LHP  *  MemoryState  ->  MemoryState 
def  read  high  func  (var  name,  mem  state)  = 

let  read  value  =  (read  high (mem  state)) .2  in 

update  variable (var  name,  read  value.  High,  mem  state) 
proof  Isa  [simp]  end-proof 


%%  function  to  assign  a  value  of  a  variable  to  a  variable  (LHP) 
op  assignl  func  :  LHP  *  RHP  *  MemoryState  ->  MemoryState 
def  assignl  func(l,  r,  mem  state)  = 

%%  find  out  the  value  of  the  variable  specified  by  RHP 
%%  then  assign  the  value  to  LHP, 

%%  if  not  variable  not  found  -  just  do  nothing 
case  r  of 

|  VarName  v  -> 

let  x  =  find  variable (v, mem  state)  in 
case  x  of 

Some  var  ->  update  variable  (1,  var. 2,  var. 3, 

mem  state) 


None  ->  mem  state 
proof  Isa  [simp]  end-proof 


%%  function  to  assign  an  integer  (RHP)  to  a  variable  (LHP) 
op  assign2  func  :  LHP  *  RHP  *  MemoryState  ->  MemoryState 
def  assign2  func(l,  r,  mem  state)  = 

%%  assign  the  value  from  RHP  to  LHP, 
case  r  of 

VarValue  v  -> 

update  variable  (1,  v.  Low,  mem  state) 
proof  Isa  [simp]  end-proof 


%%  function  to  get  value  from  variable  name, 

%%  if  variable  not  found,  zero  will  be  returned  by  default 
op  get  var  value  :  Name  *  MemoryState  ->  Value 
def  get  var  value (n, mem  state)  = 

let  x  =  find  variable (n,  mem  state)  in 
case  x  of 

Some  v  ->  v. 2 

%%  default  to  0  if  not  found 
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None  ->  0 

proof  Isa  [simp]  end-proof 
%%  Evaluate  the  conditional  statement 

%%  This  function  is  not  used,  can  be  used  in  future  to  expand  this 
work 

%%  the  if-then-else  statement  can  be  represented  using  case, 

%%  version  4.2.2  has  some  problem  with  conversion  of  case  statement 
%%  in  some  instance,  that  why  if-then=else  is  use.  This  issue  should 
be 

%%  resolved  in  version  4.2.5 

op  cond  eval?  :  LHP  *  RHP  *  Cond  *  MemoryState  ->  Boolean 
def  cond_eval? (1,  r,  cond,  mem^state)  = 
case  r  of 

VarName  v  -> 

let  x  =  get  var  value (1,  mem  state)  in 
let  y  =  get  var  value (v, mem^state)  in 
if  cond  =  GT  then 
x  >  y 

else  if  cond  =  LT  then 
x  <  y 

else  if  cond  =  GE  then 
x  >=  y 

else  if  cond  =  LE  then 
x  <=  y 

else  if  cond  =  EQ  then 
x  =  y 

else  if  cond  =  NEQ  then 
~ (x  =  y) 

%%  default  true 
else  true 
VarValue  v  -> 

let  x  =  get  var  value (1,  mem  state)  in 
let  y  =  v  in 
if  cond  =  GT  then 
x  >  y 

else  if  cond  =  LT  then 
x  <  y 

else  if  cond  =  GE  then 
x  >=  y 

else  if  cond  =  LE  then 
x  <=  y 

else  if  cond  =  EQ  then 
x  =  y 

else  if  cond  =  NEQ  then 
~ (x  =  y) 

%%  default  true 
else  true 

proof  Isa  [simp]  end-proof 
endspec 
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D. 


INITSPEC.SW 


%%  This  Specification  is  where  the  program  initial  state  and 
%%  list  of  statement  is  defined 
Init  =  spec 

import  TypeDef Spec#TypeDef 

op  initial_state  :  SystemState 
def  initial_state  :  SystemState  = 

%%  init  Variable 
( [ ( "x" , 0 ,  Low),  ( "y" , 0 ,  Low)], 

%%  init  low  input 
(  [2,7,18] ,0) , 

%%  init  high  input 
(  [4, 10,35] ,0) , 

%%  init  program 


"sO", 

Assign2 , 

"x". 

VarValue 

5, 

1 — 1 

\ — 1 

!"sl". 

ReadLow, 

"y". 

VarValue 

0, 

(2,  2)  )  , 

I"s2", 

Assignl , 

"x". 

VarName 

"y". 

(3,  3)  )  , 

!"s3". 

ReadHigh, 

"y". 

VarValue 

0, 

(4,  4)), 

;"s4". 

WriteHigh, 

"y". 

VarValue 

0, 

(5,  5)  )  , 

!  "s5" , 

WriteHigh, 

"x". 

VarValue 

0, 

(6,  6)  )  , 

"s6" , 
0)  ) 

Stop, 

ii  ii 

r 

VarValue 

0, 

(6,  6))], 

proof  Isa  [simp]  end-proof 
endspec 

E.  FILESYSTEMSPEC.SW 

%%  This  the  the  main  specification  file  modeling  the 
%%  the  *-property  of  BLP 

%%  This  specification  will  require  the  following 
%%  Specware  files: 

%%  -  TypeDef Spec . sw 

%%  -  StatementSpec . sw 

%%  -  InitSpec.sw 

%%  -  MemorySpec . sw 

FileSystem  =  spec 

%%  import  the  required  Specware  specification 
import  TypeDef Spec#TypeDef 
import  StatementSpec#Statement 
import  InitSpec#Init 

%%  system  state  transition 

op  transition  :  SystemState  ->  SystemState 
def  transition  (s)  = 

%%  as  nth  will  be  used,  it  is  required  to  confirm  the  length 
%%  of  the  list  before  proceeding,  else  Isabelle 
if  (length  s.4.1)  >  s.4.2  then 
let  vars  =  s . 1  in 
let  inputLow  =  s.2  in 
let  inputHigh  =  s . 3  in 
let  prog  =  s . 4  in 
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let  stmt  =  nth  (prog.l,  prog. 2)  in 
%%  Handle  read  low  statement 
if  stmt. 2  =  ReadLow  then 

%%  Read  from  low  input  and  assign  to  variable  specified  by 

LHS 

let  new  mem  =  read  low  func(stmt.3,  (vars,  inputLow, 
inputHigh) )  in 

%%  Update  prog  state  -  assign  next  program  counter 
let  new  prog  =  (prog.l,  stmt. 5.1)  in 

(new  mem.l,  new  mem. 2,  new  mem. 3,  new  prog) 

%%  Handle  read  high  statement 
else  if  stmt. 2  =  ReadHigh  then 

%%  Read  from  high  input  and  assign  to  variable  specified  by 

LHS 

let  new  mem  =  read  high  func(stmt.3,  (vars,  inputLow, 
inputHigh) )  in 

%%  Update  prog  state  -  assign  next  program  counter 
let  new  prog  =  (prog.l,  stmt. 5.1)  in 

(new  mem.l,  new  mem. 2,  new  mem. 3,  new  prog) 

%%  Handle  write  low  statement 
else  if  stmt. 2  =  WriteLow  then 

%%  There  is  no  output  implemented,  so  nothing  specific  to  do 

for  write 

%%  Update  prog  state  -  assign  the  next  program  counter 
let  new  prog  =  (prog.l,  stmt. 5.1)  in 
(vars,  inputLow,  inputHigh,  new  prog) 

%%  Handle  write  high  statement 
else  if  stmt. 2  =  WriteHigh  then 

%%  There  is  no  output  implemented,  so  nothing  specific  to  do 

for  write 

%%  Update  prog  state  -  assign  the  next  program  counter 
let  new  prog  =  (prog.l,  stmt. 5.1)  in 
(vars,  inputLow,  inputHigh,  new  prog) 

%%  Handle  Assignl  (X  =  Y)  statement 
else  if  stmt. 2  =  Assignl  then 

%%  assign  RHS  to  variable  specified  by  LHS 

let  new  mem  =  assignl  func(stmt.3,  stmt. 4,  (vars,  inputLow, 
inputHigh) )  in 

%%  Update  prog  state  -  increment  the  program  counter 
let  new  prog  =  (prog.l,  stmt. 5.1)  in 

(new  mem.l,  new  mem. 2,  new  mem. 3,  new  prog) 

%%  Handle  Assign2  (X  =  5)  statement 
else  if  stmt. 2  =  Assign2  then 

%%  assign  RHS  to  variable  specified  by  LHS 

let  new  mem  =  assign2  func(stmt.3,  stmt. 4,  (vars,  inputLow, 
inputHigh) )  in 

%%  Update  prog  state  -  increment  the  program  counter 
let  new  prog  =  (prog.l,  stmt. 5.1)  in 

(new  mem.l,  new  mem. 2,  new  mem. 3,  new  prog) 

%%  The  Ifthenl  statement  was  not  used,  it  can  be  extended  in 

future 

else  if  stmt. 2  =  Ifthenl  then 

%%  handle  if  then  else  statement 

let  exprval  =  (cond_eval? (stmt . 3,  stmt. 4,  GE,  (s.l,s.2, 

s . 3 ) ) )  in 
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let  next  stmt  =  if  exprval  then  stmt. 5.1  else  stmt. 5. 2  in 
let  new  prog  =  (prog.l,  next  stmt)  in 
(vars,  inputLow,  inputHigh,  new  prog) 

%%  Handle  stop  statement 
else  if  stmt. 2  =  Stop  then 
%%  return  the  current  state 
s 

else 

%%  by  default  return  the  current  state  for  unknown  statement 
s 

%%  by  defualt  return  the  current  state  for  unknown  statement 
else  s 

%%  with  [simp],  this  def  will  be  added  into  the  list  of  simplication 
rule  for  future  proofing 

proof  Isa  [simp]  end-proof 


%%  check  the  system  state  for  writing  high  to  low  (BLP  *-property) 
op  property?  :  SystemState  ->  Boolean 
def  property? (s)  = 

%%  as  nth  will  be  used,  it  is  required  to  confirm  the  length 
%%  of  the  list  before  proceeding,  else  Isabelle 
if  ((length  s.4.1)  >  s.4.2)  then 
let  stmt  =  nth ( s . 4 . 1 , s . 4 . 2 )  in 

%%  will  return  false  only  if  the  statement  is  writelow 
%%  and  the  label  of  the  variable  is  high 
if  (stmt. 2  =  WriteLow)  && 

(exists(fn  i  ->  ((i.l  =  stmt. 3)  &&  (i.3  =  High)))  (s.l)) 


then 


false 

else 

true 


else 

true 

%%  with  [simp],  this  def  will  be  added  into  the  list  of  simplication 
rule  for  future  proofing 

proof  Isa  [simp]  end-proof 


%%  This  function  will  run  n  number  of  line  of  the  program 
%%  The  function  is  of  recursive  nature,  where  it  will  recursively 
%%  call  itself  until  n  =  0,  and  the  systemstate  will  be 
%%  iniitalize  to  the  initial  state,  subsequently  transition 
%%  will  happen  until  the  initial  n  value 
op  evaluate  :  Nat  ->  SystemState 
def  evaluate (n)  = 
if  n  =  0  then 
initial  state 
else 

transition (evaluate  (n-1) ) 

%%  with  [simp],  this  def  will  be  added  into  the  list  of  simplication 
rule  for  future  proofing 

proof  Isa  [simp]  end-proof 

%%  This  function  checks  whether  the  program  counter  is  greater  than  0 
op  pcProperty?  :  SystemState  ->  Boolean 
def  pcProperty? ( s )  = 
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if  ((length  s.4.1)  >  0)  then 
true 
else 
false 

%%  with  [simp],  this  def  will  be  added  into  the  list  of  simplication 
rule  for  future  proofing 

proof  Isa  [simp]  end-proof 

%%  This  trivial  theorem  will  confirm  that  Prog  counter  will  remain 
greater  than  0 

theorem  pc  ok  is 
fa(n  :  Nat) 

pcProperty? (evaluate  (n) ) 
proof  Isa  [simp] 

apply (induct_tac  n) 
apply (auto  simp  add:  Let_def) 
end-proof 

%%  This  theorem  is  evaluate  whether  the  inputted  program  is  secure 
theorem  system  secure  is 
fa(n  :  Nat) 

property? (evaluate (n) ) 

%%  This  proof  could  not  be  complete  in  Isabelle 
%%  It  require  an  more  in  depth  understanding  of 
%%  Isabelle 
proof  Isa  [simp] 

apply (induct_tac  n) 
apply (auto  simp  add:  Let_def) 
end-proof 

endspec 
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APPENDIX  C.  BLP  MODEL 


A.  BLP.SW 

%%  Example  Implementation  of  BLP  based  on  simple  Monad  Example  which 
%%  we  created  previously 

BLP  qualifying  spec 

import  /Library/General 

type  SecLabel  =  |  TS_label  |  S_label  |  C_label  |  U_label 

%%  type  SecLabel  =  { i :  Nat  |  i  >  0  &&  i  <=  4} 
type  ResourceName  =  String 

type  Resource  =  {name:  ResourceName,  label:  SecLabel} 
type  Subject  =  Resource 
type  Object  =  Resource 

type  Mode  =  |  Read  |  Write 

type  ATTransaction  =  |  MakeKnown  |  Terminate  %%  Open  |  Close  ? 

type  AccessTuple  =  Subject  *  Object  *  Mode 

type  State  =  Set  AccessTuple 

type  Input  =  AccessTuple  *  ATTransaction 

type  InputList  =  List  Input 

%%  The  state  consists  of  just  1  variable 

%%  X:  State  [List  AccessTuple]  which  contains  allowed  transitions 
type  SystemState  =  State 

type  StateMonad  a  =  SystemState  ->  a  *  SystemState 

op  dominates  :  LinearOrder  SecLabel  = 

the  (dominates)  dominates (TS  label,  S  label) 

&&  dominates ( S_label ,  C_label) 

&&  dominates (C_label ,  U_label) 

proof  Isa  BLP  dominates  subtype  constr 
apply (simp  add:  BLP  dominates  def) 
apply (rule  tac  Q="Order  linearOrder  p"  in  thelI2) 
apply (auto  simp  add:  BLP  dominates  Obligation  the) 
end-proof 

%%  For  the  state  to  be  secure,  all  tuples  inside  the  state  must 
%%  satisfy  the  tuple_is_secure  property 
%%  Initially  the  access  tuple  list  is  empty 

%%  Checks  if  a  subject  can  access  an  object  using  a  specified  access 
%%  modebased  on  BLP  rules 

op  access_secure?  :  AccessTuple  ->  Boolean 

def  access_secure?  (subject,  object,  access_mode)  = 
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case  access_mode  of 
Read  -> 

dominates  ( sub j ect . label ,  ob j ect . label ) 

Write  -> 

dominates  (object . label,  sub j ect . label ) 

op  securestate? ( S :  State):  Boolean  = 

S  <=  access_secure? 

%%  Checks  to  see  if  the  tuple  specified  in  inside  the  current  state 
%%  Returns  true  if  tuple  exists,  false  if  tuple  does  not  exist) 

op  [a]  return  (x:a) :  StateMonad  a  =  fn  st  ->  (x,  st) 
op  [a,b]  monadBind  (ml:  StateMonad  a,  f:  a  ->  StateMonad  b) : 
StateMonad  b  = 

fn  st  ->  let  (y,stl)  =  ml  st  in 
f  y  stl 

%%  Accessory  Functions  to  retrieve  and  set  values  inside  states 
op  currently_accessible? (at :  AccessTuple) :  StateMonad  Boolean  = 
fn  (S:  State)  ->  (at  in?  S,  S) 

op  addAccess (at :  AccessTuple):  StateMonad  ()  = 
fn  (S:  State)  ->  ((),  S  <|  at) 

op  removeAccess (at:  AccessTuple):  StateMonad  ()  = 
fn  (S:  State)  ->  ((),  S  -  at) 

%%  This  corresponds  to  the  main  function  performing  the  statement 
%%  It  will  read  in  the  next  statement,  perform  it  and  then  call  next 
%%  monad  transition  is  a  fn  State  ->  Nat*State 
%%  straightforward  if  property  is  checking  based  on  the  state 
%%  variables 

op  property?:  (State)  ->  Boolean 
def  property? (s)  =  securestate? ( s ) 
proof  Isa  [simp]  end-proof 

op  transition:  Input  ->  StateMonad  Boolean 
def  transition (at,  input  transaction)  = 
case  input  transaction  of 
MakeKnown  -> 

{ 

curr?  <-  currently_accessible?  at; 
if  -curr?  &&  access_secure?  at 
then  { 

addAccess  at; 
return  true 

} 

else  return  false 

} 

Terminate  -> 

{ 

curr?  <-  currently_accessible?  at; 
if  curr? 
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then  { 

removeAccess  at; 
return  true 

} 

else  return  false 

} 

op  evalProgram:  InputList  ->  StateMonad (List  Boolean) 
def  evalProgram  (inputs)  = 
case  inputs  of 

[]  ->  return  [] 

I  inp::r  inputs  -> 

{ 

rl  <-  transition  inp; 

res  <-  evalProgram  r  inputs; 

return (rl : : res) 

} 

theorem  EmptySecure  is 
securestate? (empty) 

proof  Isa  by  (auto  simp  add:  BLP _ securestate_p_def ) 

end-proof 

theorem  transition  Terminate  subset  eq  is 
fa(S:  State,  S':  State,  at:  AccessTuple) 

(transition  (at, Terminate)  S) .2  <=  S 
proof  Isa 

apply (casejiac  "at  \_in  S") 
apply (auto  simp  add:  BLP  return  def 
BLP  monadBind  def 

BLP  currently  accessible  p  def  Let  def 
BLP  removeAccess  def) 
end-proof 

theorem  transition  MakeKnown  secure  is 

fa(S:  State,  S':  State,  at:  AccessTuple) 

access  secure?  at  =>  (transition  (at, MakeKnown)  S) .2  =  S  <| 
proof  Isa 

apply (casejiac  "at  \jiotin  S  \_and 

BLP _ access_secure_p  at") 

apply (auto  simp  add:  BLP  return  def 
BLP  monadBind  def 

BLP  currently  accessible  p  def  Let  def 

BLP _ addAccess  jief ) 

end-proof 

theorem  transition  MakeKnown  not  secure  is 
fa(S:  State,  S':  State,  at:  AccessTuple) 

~ (access_secure?  at)  =>  (transition  (at, MakeKnown)  S).2  =  S 
proof  Isa 

apply (casejiac  "at  \_notin  S  \_and  BLP _ access_secure_p  at" 

apply (auto  simp  add:  BLP  return  def  BLP  monadBind  def 
BLP  currently_accessible  p  def  Let  def 

BLP _ addAccess  jief ) 

end-proof 


at 
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theorem  transition  state  secure  is 
fa(S:  State,  input:Input) 

securestate? ( S )  =>  securestate? ( (transition  input  S).2) 
proof  Isa 

proof  (cases  input) 

show  "\  Anda  b.  \  IbrakkBLP  securestate  p  S;  input  = 

(a,  b) \  rbrakk  \  Longrightarrow  BLP  securestate  p 
(snd  (BLP  transition  input  S))" 
proof  - 
f ix  a  b 

assume  al :  "BLP _ securestate_p  S" 

assume  a2 :  "input  =  (a,  b) " 

show  "BLP  securestate  p  (snd  (BLP  transition  input  S))" 
proof  (cases  b) 
case  Terminate 

have  "snd (BLP  transition  (a, Terminate)  S) 

\_subseteq  S" 

by (rule  tac  BLP  transition  Terminate  subset  eq) 
with  'b  =  Terminate'  'input  =  (a,b) 
have  new  in  old:  "snd (BLP  transition  input  S) 

\_subseteq  S"  by  auto 

from  al  have  "S  \_subseteq  BLP  access  secure  p" 

by  (auto  simp  add:  BLP _ securestate_p_def ) 

with  new  in  old  have  "snd (BLP  transition  input  S) 

\_subseteq  BLP _ access_secure_p" 

by  (rule  subset_trans ) 

thus  Pthesis  by  (auto  simp  add:  BLP _ securestate_p_def ) 

next 

case  MakeKnown 
show  ?thesis 

proof  (cases  "BLP _ access_secure_p  a") 

case  True 
thus  Pthesis 
proof  - 

have  new  state: 

"snd (BLP  transition  (a, MakeKnown)  S)  = 
insert  a  S" 
by ( rule_tac 

BLP  transition  MakeKnown  secure) 
from  al  have  S  secure: 

"S  \_subseteq  BLP _ access_secure_p" 

by  (auto  simp  add:  BLP _ securestate_p_def ) 

with  new  state  a2  'b  =  MakeKnown' 

'BLP _ access_secure_p  a' 

show  ?thesis  by  (auto  simp  add: 

BLP  securestate  p  def  mem  def) 

qed 

next 

case  False 
thus  ?thesis 
proof  - 

have  new  state:  "snd (BLP  transition 
(a, MakeKnown)  S)  =  S" 
by (rule_tac 
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BLP  transition  MakeKnown  not  secure) 
with  al 

have  "BLP  securestate  p 

(snd  (BLP  transition  (a,  MakeKnown)  S))" 
by  auto 

with  'input  =  (a,  b)  'b  =  MakeKnown' 
show  ?thesis  by  auto 
qed 

qed 

qed 

qed 

qed 

end-proof 

endspec 
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APPENDIX  D 


LPSK  MODEL 


A.  LPSK.SW 


LpskSpec  qualifying  spec 
import  /Library/General 

Type  Definitions 

^^-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k'k-k-k-k'k-k-k-k-k-k'k-k-k-k'k-k'k-k'k-k'k-k-k-k'k-k-k-k-k-k-k-k'k-k-k'k-k-k-k-k-k'k-k  J 

type  Resourceld  =  String 

%%  Identifier  for  block 
type  Blockld 

%%  Resource 

type  Resource  =  {rscid:  Resourceld,  blkid:  Blockld, 
rscmem:  ResourceMemory } 

op  exported?:  Resource  ->  Boolean 
op  notexported? :  Resource  ->  Boolean 
op  active?:  Resource  ->  Boolean 
op  trusted?:  Resource  ->  Boolean 

type  ResourceExt  =  Resource  |  exported? 
type  Resourcelnt  =  Resource  |  notexported? 

type  ResourceActive  =  ResourceExt  |  active? 

type  Subject  =  ResourceActive 

type  TrustedSub j ect  =  Subject  |  trusted? 

%%  Set  of  resource 
type  RSet  =  Set  Resource 

type  ReSet  =  Set  ResourceExt  %%Set  of  exported  resources 
type  RiSet  =  Set  Resourcelnt  %%Set  of  internal  resources 
type  RsSet  =  Set  Subject  %%Set  of  subjects 

%%  Partitioning  of  resources  into  blocks 
%%  Block  is  a  set  of  Resource 
type  Block  =  Set  ResourceExt 

%%  set  of  blocks 
type  BSet  =  Set  Block 

%%  Memory  related 
type  Bit 

type  ResourceMemory  =  Set  Bit 
type  Memory  =  Set  Bit 
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%%  Flow  related 

type  ModeOfFlow  =  |  Read  |  Write 
type  FlowModeSet  =  Set  ModeOfFlow 

%%  Flow  effect  &  Set  of  all  possible  flow  effects 

type  Flow  =  {subj:  Subject,  obj  :  ResourceExt,  fset:  FlowModeSet} 

%%  Defines  all  effects  associated  with  an  operation/transform 
type  Transform  =  Set  Flow 
type  MM  =  Set  Transform 

type  ATTransaction  = 

MakeKnown  |  Terminate  |  ReadResourceExt  |  WriteResourceExt 

%%  Subject  to  Resource  flow  record 
type  SRMatrix  =  Set  Flow 

%%  Block  to  Block  flow  record 

%%  Represents  flow  of  information  between  blocks 
%%  BBMatrix  contains  tuples  depicting  a  Set  of  FlowModes 
%%  between  2  blocks.  If  a  BBRecord  linking  2  blocks  is  not 
%%  found,  no  allowable  flow  is  allowed  source  is  bl,  dest  is  b2 
type  BBRecord  =  {bl:  Block,  b2 :  Block,  fset:  FlowModeSet} 
type  BBMatrix  =  Set  BBRecord 

%%  Policy  is  preset  and  passed  in  during  initialisation 
type  Policy  =  { srm: SRMatrix,  bbm:  BBMatrix} 
type  Input  =  {at:  Flow,  attran:  ATTransaction} 
type  InputList  =  List  Input 

^kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

System  Definition  &  System  Property 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk^ 

type  System  =  {blocks:  BSet,  systemflows:  MM,  pol:  Policy, 
sysstate:  State} 

%%  State  contains  the  flows  that  are  currently  enabled  for  subjects, 

%%  and  also  the  set  of  system  resources 

type  State  =  {atset:  Set  Flow,  resrcset:  RSet} 

%%  Exported  resource  (Re)  \/  Internal  resource  (Ri)  =  Resource  (R) 
axiom  propertySystemSetResource  is 
fa(sys:  System) 

let  intres  =  sys . sysstate . resrcset  /\ 

(fn  (i)  ->  notexported?  (i) )  in 
let  exres  =  sys . sysstate . resrcset  /\ 

(fn  (i)  ->  exported?  (i) )  in 
(intres  \/  exres  =  sys . sysstate . resrcset)  && 

(intres  /\  exres  =  empty) 

(kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 


112 


Memory  Related  Axioms 


axiom  propertyResourceMemoryDistinct  is 
fa  (resrcl:  Resource,  resrc2 :  Resource) 

( resrcl . rscmem  /\  resrc2 . rscmem)  =  empty  | |  resrcl  =  resrc2 

^kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

State  Monad  Definition 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk\ 


type  StateMonad  a  =  State  ->  a  *  State 

op  [a]  return  (x:a) :  StateMonad  a  =  fn  st  ->  (x,  st) 
op  [a,b]  monadBind  (ml:  StateMonad  a,  f:  a  ->  StateMonad  b) : 
StateMonad  b  = 

fn  st  ->  let  (y,stl)  =  ml  st  in 
f  y  stl 

^kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

Block  Manpulation  Operations 

Needed  for  linking  resource  to  the  block  it  belongs  to  &  vice  versa 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk^ 

op  blockMatchBlockld  :  Block  *  Blockld  ->  Boolean 
def  blockMatchBlockld  (blk,  blkld)  = 

fa  (resrc:  ResourceExt)  resrc  in?  blk  =>  resrc.blkid  =  blkld 

%%  Retrieving  the  blocks  of  given  block-set  that  match  a  given 
%%  blockid 

op  filterBlock  (blockset  :  BSet,  blkld  :  Blockld)  :  BSet  = 
blockset  /\  (fn  i  ->  blockMatchBlockld ( i ,  blkld)) 

%%  Retrieve  the  block  from  a  given  block-set  that  match  a  given 
%%  blockid 

op  getBlock  (blockset  :  BSet,  blkld  :  Blockld)  :  ReSet  = 
let  bset  =  filterBlock (blockset,  blkld)  in 
if  single?  bset 
then 

theMember  bset 
else 
empty 

%%  Return  the  ID  of  a  given  block 
op  getBlockld:  Block  ->  Blockld 
def  getBlockld (blk)  = 
let  idset  =  map  (fn  i  ->  i.blkid)  blk  in 
theMember  idset 

%%  Return  the  block  id  of  a  given  resource 
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op  RB  :  ResourceExt  ->  Blockld 
def  RB(res)  =  res. bikid 

(*******************-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

Axioms  describing  property  of  Block,  RB 
Check  is  based  on  the  policy  matrix  specified 

****************-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k') 

%%  all  Block  types  are  nonempty 
axiom  BlockNotEmpty  is 

fa  (blk:  Block)  nonEmpty? (blk) 

%%  All  of  the  resources  of  a  given  Block  type  have  the  same  blkld 
axiom  BlockResourceSameBlockld  is 

fa  (blk:  Block,  resrcl:  ResourceExt,  resrc2 :  ResourceExt) 
resrcl  in?  blk  &&  resrc2  in?  blk 
=>  resrcl. blkid  =  resrc2.blkid 

%%  returns  true  if  all  blocks  in  a  given  BSet  are  distinct  and  do 
%%  not  overlap 

op  distinctSets (bset :  BSet)  :  Boolean  = 

fa (bl :  Block,  b2 :  Block) 
bl  in?  bset 
&& 

b2  in?  bset 
&& 

(bl  /\  b2  =  empty 
bl  =  b2 ) 

%%  System  element  axiom 

%%  Union  of  the  resources  of  all  blocks  equals  the  resource  set 
%%  No  other  resource  exists  other  than  those  is  sys . resources 
%%  Blocks  of  sys . resources  are  distinct 

axiom  propertyRB  is 
fa (sys:  System) 

( \ \ / /  (sys. blocks)  =  sys . sysstate . resrcset  /\  (fn  (i)  -> 
exported? ( i ) ) ) 

&& 

(full?  sys . sysstate . resrcset) 

&& 

distinctSets (sys. blocks) 

^^-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k'k'k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k'k-k-k-k 

Block  to  block  Policy  and  Flows 

Check  is  based  on  the  policy  matrix  specified 

***********-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^ 

%%  Retrieve  allowed  flows  modes  from  block  a  to  block  b  from 
%%  given  policy  matrix 
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op  BB(bb:  BBMatrix,  a:  Blockld,  b:  Blockld)  :  FlowModeSet  = 
let  bset  =  bb  /\ 

(fn  i  ->  (getBlockld ( i . bl ) =a  &&  getBlockld (i .b2) =b) )  in 
case  single?  bset  of 

true  ->  (theMember  bset) .fset 
false  ->  empty 

%%  No  other  blocks  exist  other  than  those  in  sys. blocks 
%%  All  blocks  can  both  read  and  write  to  themselves 
axiom  BB_FLOWS_BLOCK_INTERNAL_ALLOWED  is 
fa  (sys:  System,  a:  Block) 
let  bid  =  getBlockld (a)  in 
full?  sys. blocks  && 

Write  in?  BB ( sys . pol . bbm,  bid,  bid)  && 

Read  in?  BB ( sys . pol . bbm,  bid,  bid) 

^•k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

Subject  to  Resource  Policy  and  Flows 

Check  is  based  on  the  policy  matrix  specified 

*******-k'k-k-k-k'k-k'k-k'k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k'k-k^ 

%%  returns  the  modes  of  flow  allowed  between  a  given  subject  and 
%%  resource  in  a  given  SRmatrix 

op  SR(pol:  SRMatrix,  subj :  Subject,  extobj :  ResourceExt)  : 
FlowModeSet  = 

let  bset  =  pol  /\  (fn  i  ->  (i.subj  =  subj)  && 

(i.obj  =  extobj))  in 
case  single?  bset  of 

true  ->  (theMember  bset) .fset 
false  ->  empty 

axiom  SRSingleEntrySub j Ob j Pair  is 

fa  (pol:  SRMatrix,  subj:  Subject,  extobj:  ResourceExt) 
let  bset  =  pol  /\  (fn  i  ->  (i.subj  =  subj)  && 

(i.obj  =  extobj))  in 
single?  bset  | |  empty?  bset 

%%  Checks  if  a  specific  mode  of  flow  between  a  given  subject  and 
%%  resource  is  in  a  given  Transform 

op  flow  occurs? (t:  Transform,  f:  Flow,  m:  ModeOfFlow) :  Boolean  = 
m  in?  f.fset  && 
f  in?  t 

op  access  allowed?:  SRMatrix  *  BBMatrix  *  Subject  *  ResourceExt  * 
FlowModeSet  ->  Boolean 

def  access_allowed?  (srm,  bbm,  subject,  object,  am)  = 
am  <=  (SR(srm,  subject,  object))  && 
am  <=  (BB(bbm,  sub j ect . blkid,  ob j ect . blkid) ) 

op  access  secure?  :  SRMatrix  *  BBMatrix  *  Flow  ->  Boolean 

def  access_secure?  (srm,  bbm,  {subj  =  subject,  obj  =  object, 
fset  =  am})  = 

access_allowed? ( srm,  bbm,  subject,  object,  am) 
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^kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

System  state  functions. 

State  Monads  for  accessing  and  changing  the  state  variables 

•k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k} 


op  get_access_by_at  (at:  Flow) :  StateMonad  (Set  Flow)  = 

fn  (S:  State)  ->  (S.atset  /\  (fn  i  ->  ((i.subj  =  at.subj)  && 
(i.obj  =  at.obj))),  S) 

%%  Access  Functions  to  retrieve  and  set  values  inside  states 
op  currently  accessible? (at :  Flow) :  StateMonad  Boolean  = 

{ 

curr  <-  get_access_by_at  at; 

return  ((single?  curr)  &&  (at.fset  <=  (theMember  (curr) ). f set) ) 


op  add_access (at :  Flow) :  StateMonad  ()  = 

{ 

curr  <-  get_access_by_at  (at)  ; 

if  (single?  curr) 

then 

{ 

remove_access  (at) ; 

curr_at  <-  get_current_access ; 

put_current_access  (curr_at  <| 

{ 

subj  =  at.subj, 
obj  =  at.obj, 

fset  =  (theMember  (curr) ) .fset  \/  at.fset 

} 

)  ; 

return  () 

} 

else 

return  () 


op  remove_access (at :  Flow) :  StateMonad  ()  = 
fn  (S:  State)  -> 

((),  {atset  =  S.atset  --  (fn  i  ->  (i.subj  =  at.subj)  && 

(i.obj  =  at.obj)),  resrcset  =  S.resrcset}) 

op  get_current_access :  StateMonad  (Set  Flow)  = 
fn  (S:  State)  ->  (S.atset,  S) 

op  put_current_access ( inatset :  Set  Flow):  StateMonad  ()  = 

fn  (S:  State)  ->  ((),  {atset  =  inatset,  resrcset  =  S.resrcset}) 

op  read_op:  Subject  *  ResourceExt  ->  StateMonad  () 
op  write_op:  Subject  *  ResourceExt  ->  StateMonad  () 

op  get__resource :  StateMonad  (RSet)  = 
fn  (S:  State)  ->  (S.resrcset,  S) 
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op  get_resource_memory :  Resource  ->  StateMonad  (Set  Bit) 


(kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

Top  level  execution  and  initialisation  function. 

Transition  function  that  transits  the  system  state. 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk\ 


op  transition:  Input  *  System  ->  StateMonad  Boolean 
def  transition ( inp,  sys)  = 
let  policy  =  sys.pol  in 
let  at  =  inp. at  in 
let  inputtran  =  inp.attran  in 

case  inputtran  of 

MakeKnown  -> 

{ 

curr?  <-  currently__accessible?  at; 

if  -curr?  &&  access_secure? (policy . srm,  policy. bbm,  at) 
then  { 

add_access  at; 
return  true 

} 

else  return  false 

} 

Terminate  -> 

{ 

curr?  <-  currently__accessible?  at; 
if  curr? 
then  { 

remove_access  at; 
return  true 

} 

else  return  false 


ReadResourceExt  -> 

{ 

curr?  <-  currently_accessible?  at; 
if  curr? 
then  { 

b4resourceMem  <-  get  resource  memory (at . subj ) ; 
read_op (at . subj ,  at.obj); 

af terresourceMem  <-  get_resource_memory (at . subj ) ; 
return  ( 

ex  (memsect:  Set  Bit) 

- (memsect  <=  b4resourceMem) 

&& 

(memsect  <=  at . ob j . rscmem) 

&& 

(memsect  <=  af terresourceMem) 

) 

} 

else  return  false 
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} 


I  WriteResourceExt  -> 

{ 

curr?  <-  currently_accessible?  at; 
if  curr? 
then  { 

b4objMem  <-  get_resource_memory (at . obj ) ; 
write_op (at . subj ,  at. obj); 

afterobjMem  <-  get_resource_memory (at . obj ) ; 
return  ( 

ex  (memsect:  Set  Bit) 

~ (memsect  <=  b4objMem) 

&& 

(memsect  <=  at . sub j . rscmem) 

&& 

(memsect  <=  afterobjMem) 

) 

} 

else  return  false 

} 

op  evalProgram:  InputList  *  System  ->  StateMonad (List  Boolean) 
def  evalProgram  (inputs,  sys)  = 
case  inputs  of 

[]  ->  return  [] 

inp::r  inputs  -> 

{rl  <-  transition  (inp,  sys); 
res  <-  evalProgram  (r  inputs,  sys); 
return (rl : : res) } 

^***********-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

Partial  Ordering  of  BB 

Semantics  to  describe  flows  between  blocks  to  be  defined  in  such  a 
way  that  information  is  not  allowed  to  flow  circularly,  i.e.  if 
information  leaves  a  block,  there  is  no  transitive  flow  that  will 
lead  back  to  itself.  Important  to  note  that  any  2  blocks  are  not 
required  to  be  related  by  a  flow. 

*********-k-k-k-k-k-k-k-k-k-k-k-k-k'k'k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k^ 

op  direct  flow  to?(bb:  BBMatrix,  a:  Blockld,  b:  Blockld)  :  Boolean  = 
Write  in?  BB(bb,  a,  b)  %%  a  ->  b,  caused  by  a 

Read  in?  BB(bb,  b,  a)  %%  a  ->  b,  caused  by  b 

op  PO(blkset:  BSet,  bb:  BBMatrix) :  Boolean  = 
fa  (i:  Block,  j:  Block,  k:  Block) 

(i  in?  blkset)  &&  (j  in?  blkset)  &&  (k  in?  blkset)  => 

%%  Refective  Property 

direct_flow_to? (bb,  getBlockld ( i ) ,  getBlockld ( i ) ) 

&& 

%%  Antisymmetric 
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( 

(direct_flow_to? (bb,  getBlockld (i) ,  getBlockld ( j ) ) 

&& 

direct_flow_to? (bb,  getBlockld ( j ) ,  getBlockld ( i ) ) 

)  =>  (i  =  j) 

)  && 

%%  Transitive 

( 

(direct_flow_to? (bb,  getBlockld ( i )  ,  getBlockld ( j ) ) 

&& 

direct_flow_to? (bb,  getBlockld ( j ) ,  getBlockld ( k) ) 

)  =>  direct_flow_to? (bb,  getBlockld ( i ) ,  getBlockld ( k) ) 

) 

%%  BBMatrix  contains  a  set  of  BBRecord  record{block,  block,  flowset} 
%%  We  would  like  to  extract  out  the  allowed  flows  from  this,  bearing 
%%  in  mind  that  a  flow  is  a  tuple  consisting  of  a 
%%  {subject,  object,  fmode} 

op  derivebbf lowset (bbm:  BBMatrix) :  Set  Flow  = 
let  setsetflow  =  map  (bb2flowset)  bbm  in 
\ \ / /  setsetflow 

op  bb2f lowset (bb :  BBRecord) :  Set  Flow  = 

let  blsubject  =  bb.bl  /\  (fn  i  ->  active? (i) )  in 

let  b2object  =  bb.b2  in 

let  bbduple  =  blsubject  *  b2object  in 

map  (fn  (a,b)  ->  {subj  =  a,  obj  =  b,  fset  =  bb.fset})  bbduple 

Trusted  Partial  Ordering  of  BB 

Bbase:  Trusted  partial  ordering  for  system 

Trusted  Subject  is  a  Subject  that  has  undergone  rigorous  analysis  & 
is  trusted  not  to  downgrade  information  other  than  the  information 
it  is  intended  to  downgrade. 

He  is  allowed  but  not  required  to  violate  the  partial  ordering. 

Flows  will  exist  in  the  System  that  will  violate  the  partial 
ordering,  (bcontra) 

***********-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k'k-k-k'k'k-k-k-k-k'k-k-k'k-k-k-k^ 

theorem  TPO  is 

fa(sys:  System,  bbase:  BBMatrix) 

ex  (blkset:  BSet,  bcontra:  Set  BBRecord) 

%%  System  Transform  flows  will  be  totality  of  bbase  &  bcontra 
%%  Note  that  transform  flows  are  a  set  of  flows  while  BBRecord 
%%  depicts  a  flow  from  a  block  to  another  block 
%%  derivebbf lowset  extracts  all  possible  subject  to  resource 
%%  flow 

\\//sys . systemf lows  =  derivebbf lowset (bbase  \/  bcontra) 

&& 
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PO(blkset,  bbase)  && 


fa  (rs:  Resource,  r:  Resource,  f:  Set  ModeOfFlow) 

%%  Flow  must  be  allowed  in  bcontra  but  not  bbase 
f  <=  BB (bcontra,  RB(rs),  RB(r))  && 

%%  Flow  must  be  allowed  in  SR 
f  <=  SR ( ( sys . pol ) . srm,  rs,  r)  && 

%%  Upon  adding  the  equivalence  of  the  flow  from  rs  to  r, 
%%  partial  ordering  no  longer  holds  for  the  block  set  and 
%%  new  bbase 
-  ( 

PO  ( 

blkset,  (bbase  <|  {bl  =  getBlock ( sys . blocks ,  RB(rs)), 
b2  =  getBlock ( sys . blocks ,  RB(r)),  fset  =  f}) 


%%  rs  must  be  a  trusted  subject 

=>  (exported? (rs)  &&  active? (rs)  &&  trusted? (rs) ) 


Security  Theorems 


op  secure  write  transition (SI :  State,  at:  Flow) :  Boolean  = 
if  (Write  in?  at. fset)  then 

let  S'  =  (write_op  (at.subj,  at.obj)  SI) .2  in 
(  (get_resource__memory  (at.obj)  Sl).l  ~= 
(get_resource_memory  (at.obj)  S').l)  => 
(currently_accessible?  at  Sl).l 

else 

false 

op  secure_read__transition (SI :  State,  at:  Flow):  Boolean  = 
if  (Read  in?  at. fset)  then 

let  S'  =  (read_op  (at.subj,  at.obj)  SI) .2  in 
( (get_resource_memory  (at.subj)  Sl).l  ~= 
(get_resource_jnemory  (at.subj)  S').l)  => 
(currently_accessible?  at  Sl).l 

else 

false 

op  securestate? ( S :  State,  policy:  Policy):  Boolean  = 
fa(at:  Flow)  at  in?  S.atset 

=>  access_secure? (policy . srm,  policy. bbm,  at) 

%%  Resource  contains  a  set  of  bits 

%%  State  consists  of  a  policy  and  a  set  of  resources 
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theorem  EmptySecure  is 
fa(sys:  System) 

sys . sysstate . atset  =  empty  && 

secure state? (sys . sysstate,  sys . pol) 

theorem  SecureSystem  is 

fa(S:  State,  input: Input,  sys:  System) 
securestate? ( S ,  sys. pol) 

=>  securestate? ( (transition  (input,  sys)  S )  - 2 ,  sys. pol) 
&& 

secure  write  transition ( S ,  input. at) 

&& 

secure_read_transition (S,  input . at) 

endspec 
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